On 11-08-12 at 09:27am, Fabian Greffrath wrote: > Your first argument was to blame the user for not using aptitude for > upgrades. This turned out as bullshit, because even aptitude does not > remove packages that still satisfy dependencies.
I apologize for adding irrelevant and distracting noise to the bugreport. What was irrelevant and distracting was the hints on how to use aptitude. My intention of post #10 of this bugreport was to point out the ability of aptitude in fullscreen mode to spot and easily get rid of old cruft no longer part of nor supported by Debian. Also, if aptitude was used also earlier on then only if the python2.3 package was explicitly installed would it be kept around, else it would have been automatically removed when no other packages depended on it. I acknowledge that my post was crappy in not clearly passing along that message. I also acknowledge that my post could even be (mis)interpreted as rude and cynical and talking down to our users. I apologize for that. > And since the morituri package currently only depends on unversioned > python, this dependency is even satisfied by python2.3, so why remove > it. The reason for removing python2.3 is that this package was dropped before oldstable. Debian supports migrations upwards from one release to the next, not longer stretches than that. Or so I believe... > [...] some alleged policy that requires to remove old packages that > are not part of the distribution anymore on upgrades. ...and you clearly have a different opinion. > As a matter of fact, this policy does not exist. I am not surprised that it is not explicitly written in Debian Policy. > Nothing requires me to remove python2.3 on upgrades if it is not > maintained in Debian anymore. I can keep python2.3 as long as I want, > nothing forbids this. I am, however, surprised if you consider mixture of e.g. stable and oldoldstable a system supported by Debian. I consider it unsupported even though sometimes technically possible. > So what should lead to a removal of python2.3 on upgrades if not > package dependencies? Manual cleanup after a succesful upgrade to a newer release. ...or automated cleanup during upgrade by use of aptitude (i.e. not only for the upgrade but also at the time of that python2.3 package getting pulled in). > It is packages like morituri with imprecise dependencies that break > upgrades for our users. ...in your opinion. In my opinion we should help our users understand that mixtures of different releases/branches/suites of Debian is unsupported. > You say that "It is beneficial to Debian to keep package dependencies > as simple as possible." Generally I agree, but I'd also say it is even > more benefical to try as hard as possible not to break things - even > possibly unsupported corner cases. So you like "simplest possible", but favor complexity by tracking unusual corner cases - including extremes of unsupported cases. > All it took me to fix this issue was a bit of investigation [1] and > changing six (!) bytes in the Debian packaging. uhm, yes. I perfectly agre with you that your proposed change consisted of a few bytes, and that it did not require much effort to come up with that change. Don't see the point of you stating that, though. > If you cannot live with others applying such tiny changes to your pet > packages, you shouldn't have them team-maintained! You claim it is a tiny change, I do not. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers