On Sun, Nov 26, 2006 at 12:08:39AM +1100, Hamish Moffatt wrote: > > In addition, since there are no file overlaps between subsequent versions of > > libgeda, this breaks co-installability of packages built against different > > versions of libgeda for no apparent reason. If there *were* file conflicts > > between the different versions, I would say that your use of Provides: is a > > perfectly reasonable technical solution and that the only thing in need of > > fixing is the shlibs file, but as it stands I think this is a gratuitous > > deviation from Debian library best practices. Please fix libgeda so that > > the library package name matches the soname, and update the shlibs to > > match. > > Although this does mean new upstream versions of libgeda will have to go > > through the NEW queue, it also should require much less packaging work on > > the whole when updating...
> This was a working for slow NEW processing, and also for the perception > that repeated NEW processing was a bit of a nuisance in this case > because the packages are always a matched set. This is definitely a case > where it would be nice if NEW processing only applied for new sources, > not just new binaries. Hmm, it's disappointing that you felt such a workaround for NEW was necessary, especially since it does result in technically suboptimal packaging solutions. Including the current one you've just uploaded; while the shlibs are no longer in violation of policy, the package still has the problem that subsequent versions of the library aren't co-installable when they could be. This is still a bug IMHO, but not an RC one and not one I'm going to make an issue out of so long as there aren't any known real-world packages using libgeda that are from a different upstream... > > The library package name is not a release-critical issue, BTW, so if you > > insist on keeping this package name, geda won't be kicked from the release > > because of it. But the shlibs do need to be fixed. > The shlibs for libgeda20 20061020 says > libgeda 27 libgeda20 (>= 20061020) > I think this is correct - it means a sufficient version of libgeda20 is > used in the Dependences of geda-gattrib et al. In itself it doesn't > prevent a later incompatible version of libgeda meeting the dependency, > but the new libgeda will Conflict with old applications. Yes, the bug as pointed at was that third-party packages could exist that you as libgeda maintainer don't know about and therefore can't conflict with. > The only improvement I see would be to specify (>= 20061020) && > (< 20061021~0) or similar in the shlibs file. Then libgeda's would no > longer need to conflict with old versions (though the existing conflicts > would need to stay). Is this your recommendation? My recommendation was to change the libgeda package name when the upstream soname changes, really. :) > I have libgeda providing virtual package libgeda-27, but unfortunately dpkg > has a bug where it doesn't prevent libgeda20 being upgraded if it no longer > provides virtual packages required by other installed packages. Else I > could just use libgeda-NN in the shlibs file. Um, sorry, I'm afraid I don't believe you, because there are plenty of packages which depend on virtual provided packages and this bug would have shown up as a release-critical bug well before now if this were the case. I really do think that using libgeda-NN in the shlibs file would be a technically superior solution to the present one, but again it's not something I'm going to fuss over... Anyway, thanks for fixing the RC bug at least. We should be able to get the new versions hinted into testing shortly I think. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
