Paul Wise wrote: > On Thu, Aug 7, 2014 at 6:44 AM, Yavor Doganov wrote: > > Only because they don't exist. It would never occur to me to > > regenerate an image file that is already in the tarball. > > We build from source for various reasons, it is no different with > graphics: > > To ensure that your build toolchain still works at all with your > sources, you need to rebuild as often as possible.
I guess the question here is whether this is part of the "build toolchain". For packages like gfpoken it probably is. For aclock.app this is debatable, I think. There is no recipe to render the images from the .blend file. Upstream may have used specific Blender options or some further image manipulation (pngtools, etc). I could actually spoil the images in an attempt to rebuild them. Furthermore, it is possible that the current upstream has no clue at all how to generate the images -- the package was adopted by the GNUstep Application Project as it was abandoned by the original author some time ago. The .blend file and the .png files were imported in the upstream VCS in 2010 together with the whole source and were not modified since then. > Personally I would never commit generated files of any kind to my VCS > and never allow them to be added to a source tarball (except > grudgingly accepting that autotools work that way). This is usually done only for users' convenience and not because of some bad upstream intentions. It is rather annoying if you can't build a program because of some obscure dependency that cannot be installed (or is burdensome to install) for some reason. > > If there was no .blend file in the tarball and we were unaware of its > > existence, would it be a DFSG violation? > > If we had reason to believe that the PNG images were not the preferred > form for modification and that upstream was hiding their preferred > form for modification and only releasing the rendered images, then yes > I believe that is a DFSG violation. I agree. My question was would be a violation if there was no ironclad way to determine what is the preferred form for modification. > BTW, there is no need to depend on Inkscape to render SVG files as > there are other smaller renderers. Likewise for XCF files since > xcftools exists. Thanks, I didn't know that. Only one package build-depends on xcftools which again suggests that currently it is not a common practice in Debian to regenerate images from source. If you want to change that you have to enforce it somehow via Policy or at least document it as a recommended practice. That's all I wanted to say. > I wrote some best practices for upstreams about choosing the best > preferred form for modification. Thanks, that's very useful, especially for people like me who have little to no knowledge about image/sound creation/manipulation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
