Re: Upcoming dpkg 1.16.2 upload
Hi, On Wed, 29 Feb 2012, Guillem Jover wrote: Despite the circumstances, I've still managed to find some motivation to work on finishing reviewing and fixing code. Thanks for this! Last week I got the bulk of the stuff done, input interfaces, correct in-core db layout, cross-grading working and other buggy stuff fixed, with the accompanying functional test-suite cleaned up and adapted too. 1/ Have you kept reference counting of shared files? The consensus on -devel seemed that it was worth keeping it. 2/ Can you push your work in progress on pu/multiarch/master like you used to do? I'll be doing final polish and pushes during this week, and expect to be able to do an upload by the mid/end of next week. \o/ Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229110756.gb18...@rivendell.home.ouaza.com
Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
On Wed, 2012-02-15 at 16:41:21 +, Ian Jackson wrote: Guillem Jover writes (Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)): [...] But trying to workaround this by coming up with stacks of hacked up solutions [...] I disagree with your tendentious phrasing. The refcnt feature is not a hacked up solution (nor a stack of them). It is entirely normal in Debian core tools (as in any substantial piece of software serving a lot of diverse needs) to have extra code to make it easier to deploy or use in common cases simpler. All along this thread, when referring to the additional complexity and the additional hacks, I've not been talking about the refcnt'ing at all, but to all the other fixes needed to make it a workable solution. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229195152.ga4...@gaara.hadrons.org
Re: Multiarch file overlap summary and proposal
On Thu, 2012-02-16 at 10:43:53 -0800, Russ Allbery wrote: I was thinking more about this, and I was finally able to put a finger on why I don't like package splitting as a solution. We know from prior experience with splitting packages for large arch-independent data that one of the more common mistakes that we'll make is to move the wrong files: to put into the arch-independent package a file that's actually arch-dependent. This was brought up by Steve in the thread, my reply: http://lists.debian.org/debian-devel/2012/02/msg00497.html regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120301020029.ga8...@gaara.hadrons.org
Re: Multiarch file overlap summary and proposal
Guillem Jover guil...@debian.org writes: On Thu, 2012-02-16 at 10:43:53 -0800, Russ Allbery wrote: I was thinking more about this, and I was finally able to put a finger on why I don't like package splitting as a solution. We know from prior experience with splitting packages for large arch-independent data that one of the more common mistakes that we'll make is to move the wrong files: to put into the arch-independent package a file that's actually arch-dependent. This was brought up by Steve in the thread, my reply: http://lists.debian.org/debian-devel/2012/02/msg00497.html Thanks for the pointer, Guillem, but I'm afraid I don't think this reply addresses my concerns. See the specific enumeration of things that we would have to split, and the ways in which they can break. I think the issue with C headers is particularly severe. I don't think this mirrors an existing problem. The sorts of things we split into arch: all packages are nowhere near as intrusive or as tightly coupled as the things we're talking about splitting to avoid refcounting; for example, right now, splitting out C headers into arch: all packages is very rare. The sort of package splitting that we would do to avoid refcounting would run a serious risk of introducing substantial new problems that we don't currently have. The situation with refcounting seems much less fragile than the situation without refcounting to me. Refcounting puts the chance of error in the right place (on people who want to use the new feature, since the situation will not change for users who continue using packages the way they do today), provides a clear error message rather than silent corruption, and fails safely (on any inconsistency) rather than appearing to succeed in situations that are not consistent. Those are all good design principles to have. I think the principle of not changing things for people who are not using multiarch is particularly important, and is inconsistent with either package splitting or with moving files into arch-qualified paths. We should attempt to adopt new features in a way that puts most of the risk on the people who are making use of the new features, and tries to be as safe as possible for existing users. I agree that we should not pursue that to an extreme that leads to an unmaintainable system, but I don't believe refcounting has that problem. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nu9vzbb@windlord.stanford.edu
Re: Multiarch file overlap summary and proposal
On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote: Guillem Jover guil...@debian.org writes: If packages have to be split anyway to cope with the other cases, then the number of new packages which might not be needed otherwise will be even smaller than the predicted amount, at which point it makes even less sense to support refcnt'ing. I don't think the package count is really the interesting metric here, unless the number of introduced packages is very large (see below about -dev packages). I'm more concerned with maintainer time and with dependency complexity, and with the known problems that we introduce whenever we take tightly-coupled files and separate them into independent packages. Well, people have been using the amount of packages as a metric, I've just been trying to counter it. It also in a way represents the amount of work needed. About tightly-coupled files, they can cause serious issues also with refcounting, consider that there's always going to be a point when unpacking one of the new instances will have a completely different vesion than the other already unpacked instance(s). So packages could stop working for a long time if say unpacked libfoo0:i386 1.0 has file-format-0, but new libfoo0:amd64 4.0 has file-format-2, and the file didn't change name (arguably this could be considered an upstream problem, depending on the situation), this would be particularly problematic for pseudo-essential packages. I just posted separately about version lockstep: I think this is a feature, not a bug, in our multiarch implementation. I think this is the direction we *should* go, because it reduces the overall complexity of the system. [...] I've replied to that separately, in any case I think the best compromise would be to add version lockstep to dpkg, but not refcounting. Because the first is a restriction that can always be lifted if it's confirmed to cause issues (which I think it will), and the second can always be added later because it's something that allows things not permitted previously. But at this point it seems I'm alone in thinking that refcounting has more negative implications than positive ones, and I cannot get myself to care enough any longer to push for this. So some weeks ago I added back both those things to my local repo. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120301030201.gb8...@gaara.hadrons.org
