Re: Removal of transitional dummy packages
On Fri, 22 Jul 2005 12:57:14 +0200 (CEST), Santiago Vila <sanvila@unex.es> said:
> I see your point, but policy has never been a "permanent" thing.
I have no idea where you get this impression.
> 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.
There was a transition plan in progress, in which had
compatibility links in place for an extended period, and which every
developer had to follow, or else.
> 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".
No. The practice has always been to mandate smooth upgrades
between revisions, and support for upgrades skipping a release being
a desirable feature, but not a hard requirement. What is happening
here is saying that woody to etch is not feasible, due to the
large delta, so the dummy packages re cruft this time around.
This is a far cry from a policy that says that support for
upgrades skipping versions should be dropped for the future.
> 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".
The definition of cruft is packages kept around for an upgrade
path that does not ecist; in this case, woody -> etch upgrades
can't be done. Not that the upgrade was deprecated, by policy or
otherwise, but the changes made the upgrade path disappear,
unfortunately.
So woody _> etch dummy packages are cruft; Sarge -> Etch +1
may or may not be.
> 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.
Yeah, raul kinda proposed that maintianrs must support
upgrades from oldstable, but the release team has said that this is
not feasible. I think the release team has the final words here.
manoj
--
It's time to boot, do your boot ROMs know where your disk controllers
are?
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: