Re: Removal of transitional dummy packages
On Fri, 22 Jul 2005, Steve Langasek wrote:
> > > On Mon, 18 Jul 2005, Santiago Vila wrote:
> > Do you think having this in policy may be harmful? If so, why?
>
> > We supported upgrades that skip releases in the past, and now we do
> > not (I suppose the fact that our release cycles are much longer have
> > something to do with this). Isn't this the kind of thing that we
> > usually document in policy?
>
> IMHO, not really, no; I think this is more like "this is the set of
> architectures that your package must not regress on" than it is like "these
> are the arguments that your maintainer scripts must support". I.e., this is
> a temporal release team recommendation owing to the size of our deltas
> between releases right now, not a permanent policy that should be enshrined
> in the Policy document.
I see your point, but policy has never been a "permanent" thing. For some
time we have had a policy which mandated symlinks in /usr/doc. Later we had
exactly the "opposite" policy, one that does not mandate symlinks in /usr/doc.
Sometimes there is a policy which recommends something which is later
changed to a "should", then to a "must". In this case, however, we are
switching from "dummy packages for upgrades which skip releases are allowed"
to "somebody is going to file bugs on them without asking the maintainer first
and ftp.debian.org will honor the reports".
I think this is more like "things we do to support upgrades from oldstable
are considered cruft and it's ok and even desirable to remove them".
This is not limited to dummy packages, but it also includes versioned
dependencies on essential packages which everybody has now installed,
and special hacking in maintainer scripts. If we are going to remove
things because they are considered cruft, it would be very good to
have a common and consistent definition of "cruft".
There was a tentative policy regarding upgrades in Bug #34672 (you can
skip all the flames and go directly to the last message...), but it diverges
significatively from current practice. What I would like to see in
policy is our current practice, whatever it is.
Reply to: