Re: Bug#744699: Frets On Fire bug report 744699
2014-04-23 00:07 Bas Wijnen:
On Fri, Apr 18, 2014 at 03:02:30PM +0800, Paul Wise wrote:
On Fri, Apr 18, 2014 at 2:55 PM, Gianfranco Costamagna wrote:
> This is why I stopped caring about the js lintian error on sdlgfx,
> put a lintian override on debian/souce symlink and I stop caring.
This is NOT what lintian overrides are for! Lintian tells you about
things that are wrong with the package. If you stop caring, that
doesn't make it any less wrong.
Overrides should only be used for cases where lintian is wrong (that is,
when your package is a false positive) and fixing it in lintian is not
reasonable.
Adding override tags just because that makes the package lintian-clean
is a way of hiding problems instead of solving them. We promise our
users that we don't do that.
(replying because of sdlgfx)
I don't know if this point is clear from previous emails in the thread, I
haven't been reading all of it, so I will chime in to say this.
Actually, we solved the problem for the binary package, which IMO it is what
actually matters.
lintian is right that the file does not have source, but we don't ship that file
in the binary -- we link to the canonical file (from jquery package, or
something like that), which has the source in clear code, and has other benefits
(like avoiding duplication, etc).
This is equivalent to, say, removing at build time PNG files of arrows for which
we don't have the source (and perhaps the license does not apply well, for
similar reasons of source modification), and instead using ( = depending on
package and linking to its files) a canonical set of arrow images of a certain
size that many other packages use, generated from SVG files from a well-known
set of icons (e.g. KDE artwork), and that we know that the license is free, and
are more beautiful.
So, the problem is actually solved, the source-less file that lintian complains
about is not used in any way (neither build nor run time), and thus the lintian
error is misleading in a way, thus overriden.
On Fri, Apr 18, 2014 at 12:18:36AM -0700, Vincent Cheng wrote:
> Source missing: Your package contains files that need source but do
> not have it. These include PDF and PS files in the documentation, or
> auto-generated files. December 2008
I find that the language isn't particularly clear about what to do
e.g. when you have non-source files (in your source package) that
aren't actually used (by anything shipped in your binary package).
In many cases, the license of a package requires source for all files,
which means Debian is not allowed to distribute this source package if
the sources to those generated files are not available as well.
In other cases, there isn't a license problem, but it seems reasonable
to me to just have a simple rule that "we distribute source for
everything we offer"; that's what we say in our Social Contract, too.
There are hundreds of packages with cruft like Xcode/Android files, Windows
.dlls, etc; and many other files that go under the radar for which probably we
don't have the source (and see recent discussions about preferred form of
modification with artwork, for example).
Many people, including me, think that repackaging because of this issue instead
of fixing other problems (e.g., forwarding bugs upstream, keep on top of new
releases, etc.) is actually detrimental, and that we are doing a disservice to
ourselves (wasting time with boring work) and to our users (lack of quality in
other aspects) by spending time on repacking sources to remove files that users
don't even use.
Which can be argued that is also a violation of the Social Contract, if nothing
else (the vague "Our priorities are our users").
There are conflicting goals in the Social Contract, so waving hands and pointing
to it every time that this topic arises on the grounds that everything that we
offer is free, is not very helpful in my opinion. It is not universally agreed
that repackaging is a useful thing to do, or that actually the tarballs (often
pristine from upstream) is part of what we are commited to offer to our users.
(I am not keen on discussing this, just stating my opinion. I probably will not
reply to such questions in this thread).
Yes, I think that would be a very good idea indeed. It would mean that
we can say with more confidence that we provide sources and it gives our
users the ability to reasonably edit the files.
Again, we solved the problem for the binary package. The users can edit the
file from the "canonical" package, if they so wish, and have the new
functionalities/whatever not only for this package, but for any other in the
system that uses the same .js files.
Cheers.
--
Manuel
Reply to: