Tollef Fog Heen <tfheen@err.no> writes: > ]] Andreas Beckmann > >> On 2017-03-09 18:00, Ian Jackson wrote: >> > To be fair to Pirate, Andreas Beckmann suggested #856606 that if >> > Pirate disagreed with Andreas, Pirate should go to the TC. >> >> The disagreement between Pirate and me is not about the RC-ness of >> #856606, but more about the general requirement of working upgrade paths. >> >> This is my understanding of Pirate's point: >> >> "Package P hasn't been part of any stable release so far, therefore >> upgrades from earlier package versions don't have to be supported. >> So not having a working upgrade path from version 1.2-3 in testing >> to version 1.2-5 unstable is not a bug." > >>From reading through the bug log, that is my understanding of his point > as well. > > The upgrade is from a previous version of gitlab that has been in > stretch for a little under a month (it went into testing on > 2017-02-18). I think it's completely clear that failure to support > upgrades (even between short-lived versions that only hit unstable) is a > bug. For versions that hit testing, even more so. The problem with upgrades is due to the change of location of the defaults which were being read from under /usr/share/doc/ Not using /usr/share/doc/ in this way is a clear improvement. The upgradeability bug is related to the fact that the config file includes the location of the default (*.example) files, and that has changed, but being a conffile it can persist with the old setting into the running of the new version's scripts. The underlying problem is that settings that are only really useful to the first invocation of the postinst (the paths to the *.example files) are making their way into the package's configuration under /etc. One ought to be able to sort out the specific upgrade bug in an updated unstable package, but that does nothing to fix the package in stretch. I'd expect to see more bugs related to this code. I'm not sure if that counts as RC, but it seems clear that plastering over the cracks with patches to the unstable package does nothing to address the underlying problems of cruft in /etc and sloppy scripting. Unfortunately, now we're frozen, fixing the stretch package might be a problem, although if we agree that this is RC, then I guess we can still fix it :-) I'm happy to come up with a patch if that helps.[1] Cheers, Phil. [1] Moving the files out of /usr/share/doc/ and hard-wiring the new paths into the postinst would do the trick (unless there is some reason to be able to configure their location, which I cannot really imagine). I presume those settings are used nowhere else, in which case they should be renamed in the script, in order to avoid the export $(cat ...) code overwriting the new settings. Rewriting the export $(cat ...) code at the same time would be nice, but the release managers would need to decide if they think that the existing code is nasty enough to allow a bigger patch. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature