Re: O: Gnus -- A versatile News and mailing list reader for Emacsen.
On 24 Apr 2006, Bernhard R. Link spake thusly:
> * Manoj Srivastava <srivasta@debian.org> [060424 17:39]:
>>
>>> Package gnus, version x.y-z.dfsg. That way its clearly marked
>>> that gnus is modified to be dfsg free, and you dont change any
>>> source/package name. A lot of other packages in Debian already go
>>> this way, I dont see why gnus can't do it.
>>
>> In Debian, source package components have precise meaning. The
>> package name is Gnus, and the version you are referring to is the
>> "upstream" version. In case you are not aware, that implies that
>> this is a source package for an upstream release versioned
>> x.y-z.dfsg -- which in turn implies that the upstream author has
>> created a DFSG free version, perhaps unreleased, for Debian.
>>
>> I think pretending with a fake upstream version that this is the
>> same Gnus upstream packages is misleading at best, and deceptive at
>> worst.
>
> Repackaging upstream software is a common way. It is even documented
> in the Developer's reference how those are supposed to handled.
> (i.e. only remove files, not add some; the .diff.gz should contain
> some README describing how the file can be reproduced, and things
> like that)
Having something documented in the developers reference, and
calling it common, does not in any way make it less ethical in my
eyes.
> On the other hand a different source package name has also a
> specific meaning. It means it is a different source package, which
> means it is a differnt upstream or a different package. Unless you
> want to fork the package or add other files, changing the source
> name is deceptive.
>
>> Ad why is this being rejected, you may ask? On IRC, the ftp master
>> agreed that the only reason is that a one line edit is required in
>> the override file; end sers are not impacted, since gnus and
>> gnus-doc are available to them, and the only ones who work with
>> sources with apt-get source gnus would be, since they see the
>> different dir thepackage unpacks into. Not a major impact there
>> either.
>
> It's also in different directories in the package pool, which can
> also confuse people quite a bit.
Err, all they have to do is either read the Packages file, or
do an apt-cache show:
__> apt-cache show make
Package: make
Priority: standard
Section: devel
Maintainer: Manoj Srivastava <srivasta@debian.org>
Source: make-dfsg
Version: 3.81-1
Filename: pool/main/m/make-dfsg/make_3.81-1_i386.deb
MD5sum: 43ae7dacb8eb9596a28048a7910918d9
See?
>> And it is not as if there is no precedence for foo-dfsg
>> packages -- mysql-dfsg, polgen-dfsg, make-dfsg all come to mind.
>
> Two of this three examples have you as maintainter. So all you
> complain is that ftpmasters did not thought a bit before.
No, the complaint is there is no consistent policy, and we are
making policy on the fly. Which is fine, they are delegates, and can
do what they want with their standards and policies.
>> So, an inconsistent policy, all to avoid a single line edit in
>> overrides (or so it has been communicated to me).
>
> The inconsistency of policy was in my eyes to accept any of those
> before, because there is a documented normal other way to do it.
> Shall two errors force the general acceptance of it?
You can either travel back in time and create and publish a
policy, or hand wave and pretend things that are not so.
manoj
--
Beer -- it's not just for breakfast anymore.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: