Re: O: Gnus -- A versatile News and mailing list reader for Emacsen.
* Manoj Srivastava <email@example.com> [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)
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
It's also in different directories in the package pool, which can also
confuse people quite a bit.
> 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.
> 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?
Bernhard R. Link