[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#751550: RFS: aclock.app/0.4.0-1 [ITA]



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.


Reply to: