Re: How to deal with "assets" packages shadowing real upstream
On 2016-03-08 19:23, Bas Wijnen wrote:
> On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote:
>> > Oh - I just discovered that this _is_ covered by Policy §4.13 already.
> Reading that again, I see that it says code copies are acceptable if the code
> is meant to be used that way (with GNU autotools as an example in the
> footnote). For convenience, I quoted the whole thing below.
thanks for the quote (saved some time).
i think that §4.13 does not cover the original issue of jonas at all, as
it's about something different: using convenience copies instead of the
system provided packages.
the case being discussed is (i believe):
- upstream releases of "foo" contain a component "bar"
- "bar" is not an *integral* part of "foo" (it's a dependency)
- nobody has packaged "bar" yet
- may the packaging of "foo" then rely on the included "bar", or do we
have first have to package a standalone release of "bar"?
i don't think that there is anything inherently wrong using the included
"bar".
esp. if the packager actually does split the "bar" component into a
separate binary package so it's usable by other packages as well.
actually, i think in some cases it's even the better approach...think of
all that tiny js packages; wouldn't everybody be happy if they were
accumulated into a bigger upstream, even if this upstream was just a
proxy to the "real" upstreams?
however, if "bar" gets packaged on it's own (which probably only makes
sense if it provides additional features - e.g. because the repackaged
source stripped out some components and/or doesn't track upupstream's
development closely), then i guess this one should become the one to be
used by other Debian packages (conforming to §4.13).
obviously (and hopefully) after an agreement between the maintainer of
"foo" and the prospective maintainer of "bar".
fgmasdr
IOhannes
Reply to: