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

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



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.  I don't see
> the point; it seems unnecessary complication to me.

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.

To detect problems in the output, you need to rebuild as often as possible.

To gain improvements in the output, you need to rebuild as often as possible.

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).

> 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).

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. Other Debian contributors
disagree, but for now it is a requirement of the ftpmasters:

https://lists.debian.org/1948618.u6YZvnFvaf@scott-latitude-e6320
https://ftp-master.debian.org/REJECT-FAQ.html

> 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.

In almost all of these cases I would say that we are just taking
upstream's word for it or never bothered to check what upstream is
using as their preferred form of modification. In many cases they
actually threw out their preferred form of modification. In yet more
cases upstream just received some files from an artist or musician and
didn't think about how they would modify those files in future and
what the artist used as their preferred form of modification. A lot of
graphics/art/music is produced with proprietary software too.

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. Blender OTOH I think would be needed, but you can
render Blender files once and put the results in an arch:all package.

I wrote some best practices for upstreams about choosing the best
preferred form for modification. It is also useful for detecting when
the preferred form for modification is missing from the source
tarball.

http://www.freedesktop.org/wiki/Games/Upstream/#source

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


Reply to: