Re: Concerning uniliateral decision making with respect to the coreutils package

John Scott <[email protected]>
Newsgroups gmane.linux.debian.devel.general
Message-ID <[email protected]>
I appreciate your mail, Collin. For the rest of the readership I want to make a clarification that the subject line doesn't do justice on: this change has been effected through the newly-introduced coreutils-from *source* package. The coreutils source package has not made any changes made to it whatsoever. Your statement here seems accurate:
> The maintainer of the "coreutils" [source] Debian package said that he would not make this change without discussion on debian-devel, which I feel is reasonable.

To put it another way, the new src:coreutils-from source package which was accepted into Debian experimental includes an actual binary transitional package named 'coreutils' exactly. If this were to be uploaded to the unstable suite, then whichever binary package has the greater version number will "win", with the other becoming cruft.

I am concerned that this *looks* like hijacking of a binary package, by using a new source package as a vessel for a coreutils=9.7-999+0.0.0 binary package that supersedes the preexisting one coming from a different maintainer. I hope to find reassurance that this was an orderly handover that the src:coreutils maintainer consents to.

Regardless of that, the current src:coreutils-from and coreutils=9.7-999+0.0.0 package revision in experimental seems to infringe on this Debian Policy requirement: https://www.debian.org/doc/debian-policy/ch-binary.html#base-system
> You must not tag any packages essential before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached.
With the understanding that coreutils from src:coreutils-from is effectively a new package, and one which indeed has Essential: yes marked in its control file, this looks like a discrepancy. If Michael Stone for src:coreutils consented, though, then this would merely be part of the coreutils maintenance effort and not have any consequence. If the long-term plan is to detach coreutils from the src:coreutils package, then using an epoch for the binary package would be a good idea, so that the transitional package always supercedes the traditional binary package.
signature.asc (application/pgp-signature, 411 B)
-----BEGIN PGP SIGNATURE-----

iPsEABYKAKMWIQSiPzylvTnZ6xisfzWz9N0oYfTNugUCakBYX3IYaHR0cHM6Ly9q
b2huc2NvdHQubWUvLndlbGwta25vd24vbmkvc2hhLTI1Ni9zWUF3OTN6QUVrRkIy
RDREM1hOemRSeHEyMFBjNnByZGdtbEVWeXo0QUZRP2N0PWFwcGxpY2F0aW9uJTJG
cGdwLWtleXMSHGpzY290dEBwb3N0ZW8ubmV0AAoJELP03Shh9M262SgBAJurUiSj
tIKgM+y95IAXYwgabVGR87YaUksUJq5R40QzAQDNIQnGSHWl1uXZ16TdSCBaimk3
pWI+snYcXpn9YWFjBg==
=PEfs
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.