Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
Wouter Verhelst wrote:
> On Fri, Sep 04, 2009 at 08:26:10PM +0200, Luk Claes wrote:
>> Wouter Verhelst wrote:
>>>> Given the recent thread in debian-devel[1], I think we should document in
>>>> policy that packages that are not tightly related to Debian shouldn't be
>>>> native.
>>> *sigh*
>>>
>>> So I spent a whole subthread trying to explain that I think this is
>>> *not* true, and seemed to get consensus on that, and now you want to get
>>> this into policy?
>> Consensus is a big word, you managed to get people agree that if
>> maintainers really considered all the downsides even our complaints
>> from time to time that it would be acceptable...
>
> Why, yes, indeed, that's what I'm saying: that there seemed to be
> consensus on the fact that it is acceptable if people do indeed consider
> the downsides; that the "shouldn't be native" statement is wrong.
>
>>> Gee.
>>>
>>> Whether or not a native package makes sense should be the maintainer's
>>> prerogative, not decided by policy. As I said in the thread on -devel,
>>> there can be good reasons for making a package native. E.g., the
>>> maintainer doesn't have to deal with two releases (one upstream and one
>>> for debian) for every code change, but can just do one; there is
>>> immediate use of a translation team; releases are at least tested on
>>> Debian's architectures when they are released; etc.
>> When using a non-native package, the maintainer does not have to do
>> any separate release as the upstream tarball is in orig.tar.gz
>
> True. However, there will be no significant difference between making the
> package native or not in that case, IMHO.
So this argument in favour is void AFAICS.
>>> There are also obvious downsides to doing so, and it's probably a good
>>> idea to document these somewhere (though I doubt policy is the place for
>>> that; this is more something for the devref). However, outright claiming
>>> that it should not be done, will a) make a bunch of packages
>>> insta-buggy (which is bad, as far as policy is concerned), and b) is not
>>> the right thing to do, IMO.
>> They are already buggy IMHO.
>
> Perhaps, but that does not mean that they in fact are. It has been okay
> for quite a while to do this, and several packages are in fact doing so;
> changing policy does make them insta-buggy.
It certainly has not been best practice on the contrary.
> What I'd like to see before I would support this proposal (or anything
> like it), is how exactly the practice of releasing non-Debian-specific
> software as native packages is causing harm to either Debian, or the
> greater free software community as a whole; since I don't think it does,
> and I don't think we should forbid a practice which may make a
> maintainer's workflow easier if it is indeed harmless.
You still fail to explain what the package format has to do with the
work flow...
> In other words: what kind of problems do you think this will cause that
> have an effect on anyone *but* the maintainer? As said, I agree that
> documenting the problems with maintaining a package natively is a good
> thing to do, so that anyone thinking about going down that road can make
> an informed decision; but that is a far cry from what's being proposed
> here.
It has an impact on anyone dealing with the source package AFAICS. It's
also not only about an updated source package for every debian revision,
it's about an updated upstream source for every debian revision: there
might be size issues and there might be similar problems for our
downstreams than the one we face when upstream ships the debian directory.
> Sure, if something is released as a native package, that does mean that
> people repackaging the software for other distributions may want to skip
> a few releases now and then -- but I do not see how that is any
> different from, say, the vim release model, where packagers may want to
> collect a few patches before uploading a new package, rather than
> uploading a new package every time Bram releases a patch (which happens
> about every other day or some such, AIUI). Sure, maintaining software as
> a native package does introduce the requirement that the
> other-distribution-packagers know what they're doing, and that they keep
> up with development with the Debian developer who maintains the package;
> but then I would hope they would be doing that anyhow.
The difference being that the patches are released separately? So there
are no possible size issues, nor is there the problem that one might
want to remove a packaging file to customise the packaging according to
ones needs.
I still fail to see the advantages of native packages btw. I also don't
buy the argument: it was allowed before so it should stay being allowed.
Cheers
Luk
Reply to: