ifenslave hacks and policy, plus: Re: Needing explanations about BTS usage for wishlist
On Wed, Oct 19, 2005 at 02:48:09PM +0200, Jerome Martin wrote:
> Hello Mentors,
>
> After discussion in the "ifupdown-bonding package" thread, I've decided
> I wanted to submit a proposal to include some of my patches to two
> debian packages : ifenslave-2.6 and vlan (many thanks to Loic Minier for
> his patience with me). After looking at various documents and real-life
> example, I ended up with the conclusion that the correct procedure would
> be to fill in bug reports for those packages, with a wishlist severity
> and a patch tag. Could you comfirm it is the right way to do it ? Are
> there any additional things I must know/do ?
That works.
> - ifenslave is a dummy package depending on either ifenslave-2.4 or
> ifenslave-2.6. Is that what is called a "transition package" ?
I was going to say "no", but now I'm going to say "maybe", and then I
noticed what the ifenslave package is, and I think its a bug. See
below.
A transition package is a one which causes packages of some old name
to be "replaced" by packages of a new name, such that users don't lose
functionality on upgrade (which would happen, for example, if a
package was renamed, or split into multiple packages).
If a binary package is renamed, then the renamed package should be set
to Provide, Conflict, and Replace the old package, such that the new
package is installed on upgrade. That is a combination which dpkg
interprets specially. It is intuitive, though; provides: old causes
the new package to be installed on upgrade; conflicts: old causes the
old package to be removed (which is good at least for cleanliness),
and Replaces: old is necessary, otherwise there would be files
existing in both packages, and dpkg would err.
If a binary package is split, then the new packages should all
Provide, Conflict, and Replace the old one (right?). Otherwise
functionality will be lost on upgrade, and if the admin installs the
new package, they will have file overlap until they manually remove
the old one, which is a chore to be avoided.
It would be a transition package if the original "ifenslave" source
package created something like an "ifenslave" binary package, which,
the maintainer discovered, didn't work with Linux 2.6. Then the
maintainer would have modifed the package to create 2 "real" packages,
ifenslave-2.4 and ifenslave-2.6, each of which would be set to
"provide" the "virtual" package ifenslave. In this case, the
ifenslave package is a virtual transition package, necessary to not
lose functionality on upgrade; said transition package can be
"removed" (by dropping the "Provides" line) after the following stable
release (allowed because skipping stable releases is not supported).
Note that this is not the situation. See below. There is a real
package (though functionally empty) called "ifenslave" which probably
should never have been accepted into the archive.
> - I have noticed that ifenslave-2.4 is not maintained actively, and that
> last modifications applicable to both versions were only applied to
> ifenslave-2.6 by the maintainer (i.e. new if-up/if-down scripts). Is
> that something I can find explained in the policy manual, or is it left
> to the maintainer's appreciation ?
You might contact the maintainer, and if you don't receive a response,
email debian-qa@lists.d.o and ask "is this person mia" (and Cc: them
in that message).
> - Also, I noticed that a wishlist entry (in the same spirit as the one I
> want to submit) has been submitted for ifenslave, and marked as resolved
> after being implemented in ifenslave-2.6 only. Should I fill my wishlist
> entry for ifenslave or ifenslave-2.6 ?
Just ifenslave, since it appears that the packages are all
independent. (which I find strange). Can someone please confirm that
the package "ifenslave" is a hack which should be unnecessary?
Probably a policy violation, if for no other reason than the lack of a
copyright file.
--
Clear skies,
Justin
Reply to: