* Manoj Srivastava <[EMAIL PROTECTED]> [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 > either. 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. > 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? Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
