On Mar 04, Goswin von Brederlow wrote:
> > Also, why does refcounting have to be "perfect"?
> > What would break if it did not actually check that the two files
> > provided by the same package for different architectures are identical?
> Everything that can go wrong when splitting packages. You
Guillem Jover writes:
> On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote:
>> Guillem Jover 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
m...@linux.it (Marco d'Itri) writes:
> On Mar 01, Russ Allbery wrote:
>
>> The situation with refcounting seems much less fragile than the situation
>> without refcounting to me.
> I totally agree.
>
> Also, why does refcounting have to be "perfect"?
> What would break if it did not actually chec
m...@linux.it (Marco d'Itri) writes:
> On Mar 01, Russ Allbery wrote:
>> The situation with refcounting seems much less fragile than the situation
>> without refcounting to me.
> I totally agree.
> Also, why does refcounting have to be "perfect"?
> What would break if it did not actually check
On Mar 01, Russ Allbery wrote:
> The situation with refcounting seems much less fragile than the situation
> without refcounting to me.
I totally agree.
Also, why does refcounting have to be "perfect"?
What would break if it did not actually check that the two files
provided by the same package
Guillem Jover writes:
> 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
On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote:
> Guillem Jover 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 make
Guillem Jover 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-independe
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
Guillem Jover writes:
> On Wed, 2012-02-15 at 19:31:10 -0800, Russ Allbery wrote:
>> I think that the best long-term way to handle binNMUs may be to move
>> the build number into a different piece of package metadata from the
>> version. So a binNMU of a package with version 1.4-1 would still ha
On Wed, 2012-02-15 at 19:31:10 -0800, Russ Allbery wrote:
> I agree that it's asymmetric. apt-get install libfoo means libfoo:native,
> but apt-get remove libfoo means libfoo:*. And asymmetric is bad, all
> things being equal. But I think this may be one place where asymmetric is
> still the rig
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
> >
On Thu, 23 Feb 2012, Goswin von Brederlow wrote:
> > Package: 3depict
> > Source: 3depict (0.0.9-1)
> > Version: 0.0.9-1+b1
>
> Except that doesn't have to work (sorry for the ubuntu part):
>
> Package: gcc
> Source: gcc-defaults (1.93ubuntu1)
> Version: 4:4.4.3-1ubuntu1
>
> What would the versi
David Kalnischkies writes:
> On Thu, Feb 16, 2012 at 23:10, Carsten Hey wrote:
>> * David Kalnischkies [2012-02-16 03:59 +0100]:
>>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>>> (the only problem i see is that i don't have ${source:Version} available
>>> currently in the version stru
Russ Allbery writes:
> I think it would be better to have a world in which all the architectures
> of the foo package on the system have to have the same version, because
> then you don't have to treat foo:i386 and foo:amd64 like they're separate
> packages. The list of installed architectures i
Joey Hess writes:
> Goswin von Brederlow wrote:
>> pkg:arch will still be unique and the dpkg/apt output will use the
>> architecture where required for uniqueness. So I think that after some
>> getting used to it it will be clear enough again.
>
> Here are a few examples of the problems I worry
Josselin Mouette writes:
> Le lundi 13 février 2012 à 22:43 -0800, Russ Allbery a écrit :
>> There's been a lot of discussion of this, but it seems to have been fairly
>> inconclusive. We need to decide what we're doing, if anything, for wheezy
>> fairly soon, so I think we need to try to dr
Russ Allbery writes:
> Carsten Hey writes:
>> * Russ Allbery [2012-02-16 14:55 -0800]:
>
>>> Every file that differs has to be fixed in the current multi-arch plan.
>>> Documentation that contains its build date is going to need to be split
>>> out into a separate -docs package.
>
>> I doubt tha
Russ Allbery writes:
> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:
>
> * dpkg re-adds the refcounting implementation for multiarch, but along
> with a Policy requirement that packages that are multiarch
Jonathan Nieder writes:
> Jonathan Nieder wrote:
>> David Kalnischkies wrote:
>
>>> Why would it be intuitive to add a specific value for the arch attribute
>>> with
>>> apt-get install foo # arch |= native
>>> but remove all values of the attribute with
>>> apt-get remove foo# arch &= ~al
On Fri, Feb 17, 2012 at 19:53, Carsten Hey wrote:
> * David Kalnischkies [2012-02-17 14:15 +0100]:
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library ...
>
> My impression was that you think very library centric. All I wrote was
* David Kalnischkies [2012-02-17 17:20 +0100]:
> Why would it be intuitive to add a specific value for the arch attribute with
> apt-get install foo # arch |= native
> but remove all values of the attribute with
> apt-get remove foo# arch &= ~all-architectures
> ?
We had a similar discussion
* David Kalnischkies [2012-02-17 14:15 +0100]:
> You generously left out the paragraph describing how APT should
> detect that the package foo is in fact a library ...
My impression was that you think very library centric. All I wrote was
(in other words), that we should consider non-library pack
Jonathan Nieder wrote:
> David Kalnischkies wrote:
>> Why would it be intuitive to add a specific value for the arch attribute with
>> apt-get install foo # arch |= native
>> but remove all values of the attribute with
>> apt-get remove foo# arch &= ~all-architectures
>> ?
[...]
> But I real
David Kalnischkies wrote:
> Why would it be intuitive to add a specific value for the arch attribute with
> apt-get install foo # arch |= native
> but remove all values of the attribute with
> apt-get remove foo# arch &= ~all-architectures
> ?
>
> Isn't it more intuitive to have it this way:
On Fri, Feb 17, 2012 at 15:46, Jonathan Nieder wrote:
> David Kalnischkies wrote:
>
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library and not, say, a
>> plugin, a dev-package, a dbg-package or a future-coinstallable binary.
>> An
David Kalnischkies wrote:
> You generously left out the paragraph describing how APT should
> detect that the package foo is in fact a library and not, say, a
> plugin, a dev-package, a dbg-package or a future-coinstallable binary.
> And the foo:* default would be okay and intuitive for all of tho
On Thu, Feb 16, 2012 at 23:10, Carsten Hey wrote:
> * David Kalnischkies [2012-02-16 03:59 +0100]:
>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>> >>> it needs to find and remove foo:*
>
> foo:all (or foo:any) instead of foo:* would save the need to quote it.
:all is already an archit
Carsten Hey writes:
> * Russ Allbery [2012-02-16 14:55 -0800]:
>> Every file that differs has to be fixed in the current multi-arch plan.
>> Documentation that contains its build date is going to need to be split
>> out into a separate -docs package.
> I doubt that ftpmaster would be happy about
* Russ Allbery [2012-02-16 14:55 -0800]:
> Carsten Hey writes:
> > There are still files that differ that do not need to be fixed, for
> > example documentation that contains it's build date.
>
> Every file that differs has to be fixed in the current multi-arch plan.
> Documentation that contains
Carsten Hey writes:
> * Russ Allbery [2012-02-16 10:43 -0800]:
>> * Users who want to co-install separate architectures will immediately
>> encounter a dpkg error saying that the files aren't consistent. This
>> means they won't be able to co-install the packages, but dpkg will
>> prevent
* Russ Allbery [2012-02-16 10:43 -0800]:
> * Users who want to co-install separate architectures will immediately
> encounter a dpkg error saying that the files aren't consistent. This
> means they won't be able to co-install the packages, but dpkg will
> prevent any actual harm from happeni
* David Kalnischkies [2012-02-16 03:59 +0100]:
> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
> >>> it needs to find and remove foo:*
foo:all (or foo:any) instead of foo:* would save the need to quote it.
> > Actually, why would that be the behavior? Why would dpkg --purge foo not
> > j
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
On Thu, Feb 16, 2012 at 09:26, Goswin von Brederlow wrote:
> Russ Allbery writes:
>> David Kalnischkies writes:
>>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>>
Actually, why would that be the behavior? Why would dpkg --purge foo
not just remove foo for all architectures for
Russ Allbery writes:
> David Kalnischkies writes:
>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>
>>> Actually, why would that be the behavior? Â Why would dpkg --purge foo
>>> not just remove foo for all architectures for which it's installed, and
>>> require that if you want to remove
Russ Allbery writes:
> David Kalnischkies writes:
>> Maybe it would help this kind of discussions if we would have a list of
>> interface changes in dpkg and how someone is supposed to use it in the
>> future in case this has changed - i personally lost track of that. (In
>> case someone wants
David Kalnischkies writes:
> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>> Actually, why would that be the behavior? Why would dpkg --purge foo
>> not just remove foo for all architectures for which it's installed, and
>> require that if you want to remove only a specific architecture y
On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
> Ian Jackson writes:
>> Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
>
>>> Here are a few examples of the problems I worry about. I have not
>>> verified any of them, and
Guillem Jover 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 pac
Ian Jackson writes:
> Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
>> Here are a few examples of the problems I worry about. I have not
>> verified any of them, and they're clearly biased toward code I am
>> familiar with, which s
Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
> Goswin von Brederlow wrote:
> > pkg:arch will still be unique and the dpkg/apt output will use the
> > architecture where required for uniqueness. So I think that after some
> > getting used to i
Russ Allbery writes ("Re: Multiarch file overlap summary and proposal"):
> I definitely agree on the complexity this adds. But I don't think there's
> an alternative to that complexity without using something like --sysroot
> or mini-chroots, and I don't think
Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was:
Summary: dpkg shared / reference counted files and version match)"):
> On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote:
> > I think the refcounting approach is very worthwhile becaus
Goswin von Brederlow wrote:
> pkg:arch will still be unique and the dpkg/apt output will use the
> architecture where required for uniqueness. So I think that after some
> getting used to it it will be clear enough again.
Here are a few examples of the problems I worry about. I have not
verified a
Russ Allbery writes:
> Joey Hess writes:
>
>> Anyway, my worry about the refcounting approach (or perhaps M-A: same in
>> general) is not the details of the implementation in dpkg, but the added
>> mental complexity of dpkg now being able to have multiple distinct
>> packages installed under the
Ian Jackson writes:
> Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was:
> Summary: dpkg shared / reference counted files and version match)"):
>> This still does not solve the other issues I listed, namely binNMUs
>> have to be performed in
Ian Jackson writes:
> Russ Allbery writes ("Multiarch file overlap summary and proposal (was:
> Summary: dpkg shared / reference counted files and version match)"):
>> 5. Data files that vary by architecture. This includes big-endian
>>vs. little-endi
On Tue, 14 Feb 2012, Guillem Jover wrote:
> I've never proposed to arch-qualify the filename for the stuff under
> /usr/share/doc/pkgname/, I've proposed to arch-qualify the pkgname in
> the path (/usr/share/doc/pkgname:arch/), but only for M-A:same packages,
> which are the only ones needing the d
Joey Hess writes:
> Anyway, my worry about the refcounting approach (or perhaps M-A: same in
> general) is not the details of the implementation in dpkg, but the added
> mental complexity of dpkg now being able to have multiple distinct
> packages installed under the same name. I had a brief expo
Guillem Jover wrote:
> Aside from what I said on my other reply, I just wanted to note that
> this seems to be a recurring point of tension in the project when it
> comes to archive wide source package changes, where supposed short
> term convenience (with its usually long term harmful effects) app
On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote:
> I think the refcounting approach is very worthwhile because it
> eliminates unnecessary work (by human maintainers) in many simple
> cases.
Aside from what I said on my other reply, I just wanted to note that
this seems to be a recurring p
Niels Thykier writes:
> On 2012-02-14 07:43, Russ Allbery wrote:
>> [...]
>>
>> * Lintian should recognize arch-qualified override files, and multiarch:
>> same packages must arch-qualify their override files. debhelper
>> assistance is desired for this.
>>
>> [...]
> I have no problem wit
On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote:
> Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was:
> Summary: dpkg shared / reference counted files and version match)"):
> > On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote:
>
On Tue, 14 Feb 2012, Marvin Renich wrote:
> I thought Goswin's suggestion in [1] of having dpkg use implicit
> diversions has merit and deserves further scrutiny.
I don't. diversions support 2 packages, the "diverted" one and the
"diverting" one. Multi-Arch: same must support co-installation of
an
On Tue, 14 Feb 2012, Jakub Wilk wrote:
> Are we sure than no existing package uses debian/changelog.build for
> their own purposes?
No, but with debian/changelog.dpkg-build we should be safe.
> Are we sure that all existing packages (and helpers) that parse
> debian/changelog use dpkg-parsechange
* Russ Allbery [120214 01:48]:
> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:
I thought Goswin's suggestion in [1] of having dpkg use implicit
diversions has merit and deserves further scrutiny. It essent
Hi,
On Tue, 14 Feb 2012, Sven Joachim wrote:
> > Guillem Jover writes:
> >
> >> This still does not solve the other issues I listed, namely binNMUs
> >> have to be performed in lock-step, more complicated transitions /
> >> upgrades.
> >
> > I don't think I see where this is coming from. Are you
Hi,
On Tue, 14 Feb 2012, Guillem Jover wrote:
> > * All packages that want to be multiarch: same have to move all generated
> > documentation into a separate package unless the maintainer has very
> > carefully checked that the generated documentation will be byte-for-byte
> > identical even
On 2012-02-14 15:28 +0100, Ian Jackson wrote:
> Guillem Jover writes:
>
>> This still does not solve the other issues I listed, namely binNMUs
>> have to be performed in lock-step, more complicated transitions /
>> upgrades.
>
> I don't think I see where this is coming from. Are you talking about
Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was:
Summary: dpkg shared / reference counted files and version match)"):
> On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote:
> > * The binNMU process is changed to add the binNMU changelog ent
* Raphael Hertzog , 2012-02-14, 14:17:
dpkg-buildpackage --binary-version --binary-changelog 'foo' could
create debian/changelog.build with the given changelog version and
changelog entry.
dpkg-parsechangelog could be taught to read debian/changelog.build
before debian/changelog so that dpkg
Le lundi 13 février 2012 à 22:43 -0800, Russ Allbery a écrit :
> There's been a lot of discussion of this, but it seems to have been fairly
> inconclusive. We need to decide what we're doing, if anything, for wheezy
> fairly soon, so I think we need to try to drive this discussion to some
> concr
Russ Allbery writes ("Multiarch file overlap summary and proposal (was:
Summary: dpkg shared / reference counted files and version match)"):
> There's been a lot of discussion of this, but it seems to have been fairly
> inconclusive. We need to decide what we're doin
On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote:
> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:
> * dpkg re-adds the refcounting implementation for multiarch, but along
> with a Policy requiremen
On Tue, 14 Feb 2012, Philipp Kern wrote:
> On 2012-02-14, Raphael Hertzog wrote:
> > Somehow my suggestion is then to extend dpkg-parsechangelog to provide
> > the required logic to split the changelog in its bin-nmu part and its
> > usual content.
> >
> > dpkg-parsechangelog --split-binnmu
> >
On 2012-02-14 07:43, Russ Allbery wrote:
> [...]
>
> * Lintian should recognize arch-qualified override files, and multiarch:
> same packages must arch-qualify their override files. debhelper
> assistance is desired for this.
>
> [...]
I have no problem with Lintian accepting arch-qualified
On 2012-02-14 07:43, Russ Allbery wrote:
> 4. Lintian overrides. I believe these should be qualified with the
>architecture on any multiarch: same package so that the overrides can
>vary by architecture, since this is a semi-frequent use case for
>Lintian.
> * Lintian should recogniz
On Mon, 13 Feb 2012, Russ Allbery wrote:
> There's been a lot of discussion of this, but it seems to have been fairly
> inconclusive. We need to decide what we're doing, if anything, for wheezy
> fairly soon, so I think we need to try to drive this discussion to some
> concrete conclusions.
Thank
There's been a lot of discussion of this, but it seems to have been fairly
inconclusive. We need to decide what we're doing, if anything, for wheezy
fairly soon, so I think we need to try to drive this discussion to some
concrete conclusions.
First, Steve's point here is very good:
Steve Langase
70 matches
Mail list logo
