On Tue, Nov 04, 2008 at 10:03:54PM +0100, Jonas Smedegaard wrote: > I also only see three packages depending. I did not check all > architectures, however. And more importantly, I did not check > build-depends!
Right, I didn't think of those, and the large number of them does complicate things. I'd expect them not to require the X11 driver, but that's just a guess and not even a particularly educated one. If this avenue is still worth looking at, an adequate semi-automatic check might be to verify that the corresponding packages do build without ghostscript-x, and that the resulting packages are similar enough to those in the archive. I agree it's very late in the release process for this. > Any hint on looking up reverse build-dependencies somehow? I use grep-dctrl for things like this. > > While it would certainly be good to fix this is a point release, we > > haven't required upgrading through point releases in the past AFAIK, > > and I think anyone would have a hard time pushing for that now. > > I believe we did so for Linux kernels for Sarge (due to 2.4.x -> 2.6.x > transition for many archs and problems switching from initrd-tools to > either initramfs-tools or yaird). > > And again in Etch we bumped both initramfs-tool and yaird in etchnhalf - > I haven't checked it out, but expect upgrade instructions to include > upgrading to etchnhalf before upgrading to Lenny. OK, if that is the case, I'd be OK with a fixed gs-common.prerm in a point release and a mention in the release notes that 'aptitude install gs-common' is a way out of the situation. > >> 3) Have aptitude (and, if possible, APT generally) include a hint > >> that gs-common should not be auto-removed by default, and add to > >> upgrade procedures to install newest aptitude before dist-upgrading. > > > > Hm, that's a novel idea. > > No, not really. Already exercised for Linux kernels: Have a look on a > Lenny/Sid at /etc/apt/apt.conf.d/01autoremove :-) Ah, thanks. I wasn't aware of this. I believe we already recommend upgrading aptitude first, so that would indeed help. > How about this approach, then: Consider this a corner case, lower to > some non-RC level and leave it hanging...? As long as at least some of the mitigations mentioned above do get implemented, I'm OK with this. Do the release folks have any opinion? -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
