Hello World,
Thank you for the amazing work!
I have been working on the packaging of ldraw for the conda package manager (both ldraw-parts and ldraw-list) and I have come across a couple of pitfalls I wanted to report back - even though it is not completely a blocker for moving forward.
1. mklist
- The mklist package does not build out of the box. Everyone (FreeBSD, Debian, ArchLinux) appears to be applying the same patches to the makefile and sources so that it builds succesfully (and I had to do so as well). It may be worth including these patches upstream and bump the version of mklist which has not been updated in a while. If the package was hosted on GitHub or GitLab, it may be easier to submit patches back.
- The mklist source tarball is included in the parts zip file, including built artefacts for windows. Since it is a very simple program, I think that it is fine to provide a built executable on the website, although the parts library and mklist may be better separated.
- Quick note if anyone on this forum is involved in the debian packaging: the version number for the ldraw-mklist debian package appears to be the same as for parts library, while it should really be 1.6.
2. Persistent source tarballs for the parts library
It seems that with every update of the parts library, the new parts are uploaded in a separate zip file, while the complete.zip file is overwritten with the new version of the full library.
This may be an issue because old versions of complete.zip are not available anymore and we can't use a persistent URL for a given version. If you kept a complete-????.zip around for each release, we would be able to point to it persistently.
I am looking forward to hearing back, and super excited to work on the packaging of the lego CAD stack for conda!
Cheers,
Thank you for the amazing work!
I have been working on the packaging of ldraw for the conda package manager (both ldraw-parts and ldraw-list) and I have come across a couple of pitfalls I wanted to report back - even though it is not completely a blocker for moving forward.
1. mklist
- The mklist package does not build out of the box. Everyone (FreeBSD, Debian, ArchLinux) appears to be applying the same patches to the makefile and sources so that it builds succesfully (and I had to do so as well). It may be worth including these patches upstream and bump the version of mklist which has not been updated in a while. If the package was hosted on GitHub or GitLab, it may be easier to submit patches back.
- The mklist source tarball is included in the parts zip file, including built artefacts for windows. Since it is a very simple program, I think that it is fine to provide a built executable on the website, although the parts library and mklist may be better separated.
- Quick note if anyone on this forum is involved in the debian packaging: the version number for the ldraw-mklist debian package appears to be the same as for parts library, while it should really be 1.6.
2. Persistent source tarballs for the parts library
It seems that with every update of the parts library, the new parts are uploaded in a separate zip file, while the complete.zip file is overwritten with the new version of the full library.
This may be an issue because old versions of complete.zip are not available anymore and we can't use a persistent URL for a given version. If you kept a complete-????.zip around for each release, we would be able to point to it persistently.
I am looking forward to hearing back, and super excited to work on the packaging of the lego CAD stack for conda!
Cheers,