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

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,

        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.

It's time to boot, do your boot ROMs know where your disk controllers
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: