On Mar 04, Goswin von Brederlow goswin-...@web.de 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
m...@linux.it (Marco d'Itri) writes:
On Mar 01, Russ Allbery r...@debian.org 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
Guillem Jover guil...@debian.org writes:
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
On Mar 01, Russ Allbery r...@debian.org 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
m...@linux.it (Marco d'Itri) writes:
On Mar 01, Russ Allbery r...@debian.org 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
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
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 right
Guillem Jover guil...@debian.org 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
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 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
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
Guillem Jover guil...@debian.org 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
Russ Allbery r...@debian.org 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
Russ Allbery r...@debian.org writes:
Carsten Hey cars...@debian.org 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
Josselin Mouette j...@debian.org 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
Joey Hess jo...@debian.org 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
Russ Allbery r...@debian.org 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
David Kalnischkies kalnischk...@gmail.com writes:
On Thu, Feb 16, 2012 at 23:10, Carsten Hey cars...@debian.org wrote:
* David Kalnischkies [2012-02-16 03:59 +0100]:
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org wrote:
(the only problem i see is that i don't have
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 version be for a
Jonathan Nieder jrnie...@gmail.com 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 =
* Russ Allbery [2012-02-16 14:55 -0800]:
Carsten Hey cars...@debian.org 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
Carsten Hey cars...@debian.org 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
On Thu, Feb 16, 2012 at 23:10, Carsten Hey cars...@debian.org wrote:
* David Kalnischkies [2012-02-16 03:59 +0100]:
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org wrote:
it needs to find and remove foo:*
foo:all (or foo:any) instead of foo:* would save the need to quote it.
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 those?
On Fri, Feb 17, 2012 at 15:46, Jonathan Nieder jrnie...@gmail.com 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
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:
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 really think
* 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
* 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
On Fri, Feb 17, 2012 at 19:53, Carsten Hey cars...@debian.org 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
Russ Allbery r...@debian.org writes:
David Kalnischkies kalnischk...@gmail.com writes:
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org 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,
On Thu, Feb 16, 2012 at 09:26, Goswin von Brederlow goswin-...@web.de wrote:
Russ Allbery r...@debian.org writes:
David Kalnischkies kalnischk...@gmail.com writes:
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org wrote:
Actually, why would that be the behavior? Why would dpkg
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
* David Kalnischkies [2012-02-16 03:59 +0100]:
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org 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
* 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 happening.
Carsten Hey cars...@debian.org 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
Ian Jackson ijack...@chiark.greenend.org.uk 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-endian issues.
Ian Jackson ijack...@chiark.greenend.org.uk 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 lock
Russ Allbery r...@debian.org writes:
Joey Hess jo...@debian.org 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
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 any
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 because it
eliminates unnecessary work
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 those are satisfying solutions
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 it it will be clear enough again.
Here
Ian Jackson ijack...@chiark.greenend.org.uk 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 suggests
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
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org wrote:
Ian Jackson ijack...@chiark.greenend.org.uk 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
David Kalnischkies kalnischk...@gmail.com writes:
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org 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 r...@debian.org writes:
David Kalnischkies kalnischk...@gmail.com 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
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 recognize
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 Tue, 14 Feb 2012, Philipp Kern wrote:
On 2012-02-14, Raphael Hertzog hert...@debian.org 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
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 requirement
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 doing, if anything, for wheezy
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
concrete
* Raphael Hertzog hert...@debian.org, 2012-02-14, 14:17:
dpkg-buildpackage --binary-version ver --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
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 entry to an
arch-qualified
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
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 across
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 talking about
* Russ Allbery r...@debian.org [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
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
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
any
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:
* The binNMU process is changed
Niels Thykier ni...@thykier.net 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
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
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)
Joey Hess jo...@debian.org 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
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
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.
Thanks
69 matches
Mail list logo
