[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: O: Gnus -- A versatile News and mailing list reader for Emacsen.

* 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)

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?

  Bernhard R. Link

Reply to: