Paul Gevers wrote: > On 06-08-14 13:57, Yavor Doganov wrote: > > That's news to me. > > Is it? I thought I saw you doing the same thing with the some xpm > files in multiple GNUstep packages.
Only because they don't exist. It would never occur to me to regenerate an image file that is already in the tarball. I don't see the point; it seems unnecessary complication to me. > Well, I do it in multiple of my packages, e.g. in Winff to create the > pdfs from Libre Office files. Maybe it has some merit in this case -- what you do ensures that the PDF files are always current (in the case where upstream has modified the LibreOffice files but forgotten to regenerate the PDFs). (I wouldn't do it for my packages because libreoffice is not available on about half of the architectures. It doesn't do any harm to winff, though.) > An alternative would be to create a target in the rules file that > can be used once in a while to check it is possible. I could try to do that, if I'm convinced there is a compelling reason... > > A far more serious concern is whether the .gorm files will be > > loadable with future gnustep-gui releases or editable with future > > gorm.app versions. > > Can you help me a bit, how does this work? Are the .gorm files in the > packages created by the maintainer? Are they the source files, or > created during building? The .gorm files are created by the upstream developers, with Gorm. They are the source and the "executable", no building is required. During building, they are simply copied into the resource bundle. A .gorm file is loaded dynamically at runtime. The file is first unarchived, then all objects are decoded, allocated and initialized. .gorm files do not only describe the UI (like .ui or .glade files in the GTK+/GNOME world), they have the object connections/relationship and whole classes encoded so they may form a considerable part of the program. As the format has changed a few times in the past, a file created with a newer version of Gorm (or the corresponding proprietary tool on MuckOS X) is not always guaranteed to be loaded by an older GNUstep installation. In rare cases, a .gorm file may not be loaded successfully by some random versions of gnustep-gui, typically when it was created by a very old or buggy Gorm version (we had one case like this in Debian -- I don't remember if we patched it with uuencode or just removed the package, most probably the latter). Upstream strives very hard to preserve compatibility, but as usual there is no guarantee. AClock with a broken .gorm file will be completely useless, while the outdated cuckoo will work just fine. > Well, it comes from me as I had to ask you during the reviewing how > this all works. If it is documented, you don't need to do the same > next time If there was no .blend file in the tarball and we were unaware of its existence, would it be a DFSG violation? PNG files are editable, and it could be possible, in theory and in practice, that this cuckoo animation is created/maintained in a manual fashion (I'm not familar with graphics design practices, so I may be wrong here). I anticipate there are hundreds of thousands of images in the archive, and most probably some of them do not have the corresponding source (or perhaps more accurately said, preferred form of modification). Most definitely, those that have the source available are not using it to regenerate the image files, or else there ought to be a lot of inkscape/gimp/blender build-deps. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx5pgrvq.GNUs_not_UNIX!%ya...@gnu.org
