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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
