Jakub Wilk dixit:
>> * binNMUs for the same version cannot be co-installed anyway as their
>> changelogs differ.
>> ↓
>> That could be “fixed” by using the same email address and a hardcoded
>> date, or not including the binNMU entry at all, or moving that entry to a new
>> field, etc. All of whic
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
> >
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
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
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
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, 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
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
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 Sat, 2012-02-11 at 03:28:33 +0200, Riku Voipio wrote:
> * Because shared files packaging simpler for maintainers.
>
> Package profiliation and duplication of arch-independent data are merely
> effecty that happen when packagers workaround the lack of shared identical
> files.
That way of thin
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 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
* Guillem Jover [2012-02-10 23:56 +0100]:
> * binNMUs for the same version might not be co-installable because doc
> generators, compressors, etc, might not always produce the same output.
>
> ... A possible fix, but only for the compressed files case might be to
> ship them uncompresesd, but
On Fri, Feb 10, 2012 at 05:35:19PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > On Fri, Feb 10, 2012 at 06:56:00PM -0600, Jonathan Nieder wrote:
> >> I agree that the extra work of removing "multi-arch: same" for existing
> >> -dev packages that have been converted is a major downside.
Raphael Hertzog writes:
> Hello,
>
> On Sat, 11 Feb 2012, Jakub Wilk wrote:
>> >* Deploying refcnt means that M-A:same packages must always be at
>> >the same exact installed version, so that the file contents can
>> >match.
>> >â
>> >More difficult upgrade paths, as this ties the different arc
Stefano Zacchiroli writes:
> On Fri, Feb 10, 2012 at 05:35:19PM -0800, Russ Allbery wrote:
>> We need a guarantee that gzip will always produce the same output, which
>> we already know isn't the case and which doesn't look sustainable going
>> forward.
>
> My understanding of #647522 is differen
Jonathan Nieder writes:
> Hi,
>
> Jakub Wilk wrote:
>
>> How about:
>> * Because this the obvious and elegant way of doing things. It makes
>> multiarchification easy for packagers, and invisible for uses,
>> including those users who don't care about multi-arch (unless they
>> rely on paths to t
m...@linux.it (Marco d'Itri) writes:
> As the maintainer of a few (popular) library packages I consider
> splitting these packages a complex and annoying workaround for
> deficiencies in tools.
> It is not true that splitting the package is a one time action, every
> release which adds new file
On Sat, 11 Feb 2012 06:21:52 -0800
Russ Allbery wrote:
> Guillem Jover writes:
> > On Sat, 2012-02-11 at 11:41:58 +0100, Stefano Zacchiroli wrote:
>
> >> That is a bug and ought to be fixed in its own right. Then, the
> >> discussion of how much we should rely on it or not is a different one,
>
Guillem Jover writes:
> On Sat, 2012-02-11 at 11:41:58 +0100, Stefano Zacchiroli wrote:
>> That is a bug and ought to be fixed in its own right. Then, the
>> discussion of how much we should rely on it or not is a different one,
>> but it's good to separate the concerns.
> As mentioned on the su
On Sat, 2012-02-11 at 00:46:53 +0100, Marco d'Itri wrote:
> It is not true that splitting the package is a one time action, every
> release which adds new files will require dealing with the split.
Assuming a somewhat standard packaging, using debhelper and debian/tmp
or debian/, where all upstre
On Sat, 2012-02-11 at 11:41:58 +0100, Stefano Zacchiroli wrote:
> That is a bug and ought to be fixed in its own right. Then, the
> discussion of how much we should rely on it or not is a different one,
> but it's good to separate the concerns.
As mentioned on the summary, this is not specific to
On Fri, 2012-02-10 at 17:16:29 -0800, Steve Langasek wrote:
> On Fri, Feb 10, 2012 at 06:56:00PM -0600, Jonathan Nieder wrote:
> > As long as dependencies are accurate, I don't see how allowing
> > co-installation of the same package for two different architectures at
> > different versions is any
* Jonathan Nieder , 2012-02-10, 18:56:
This is not so one-sided as you seem to be suggesting.
Yes. I apologize for implying this.
Jonathan
who wishes he knew of a fifth approach without the downsides of the
others proposed so far :)
Let me try:
1. We allow sharing files between architectu
On Sat, 11 Feb 2012 03:28:33 +0200
Riku Voipio wrote:
> Package proliferation and duplication of arch-independent data are merely
> effects that happen when packagers workaround the lack of shared identical
> files.
+1
> One solution for the binNMU changelogs and generated docs would be to
> us
On Sat, 11 Feb 2012, Henrique de Moraes Holschuh wrote:
> On Sat, 11 Feb 2012, Raphael Hertzog wrote:
> > It could be a source of subtle bugs if this leads to having
> > libfoo:i386 (1.0) + libfoo:amd64 (2.0) + libfoo-data:all (2.0)
> >
> > But then the proper answer is for the maintainer to put
>
* Raphael Hertzog , 2012-02-11, 11:15:
* Deploying refcnt means that M-A:same packages must always be at the
same exact installed version, so that the file contents can match.
↓
More difficult upgrade paths, as this ties the different arch
dependency trees around M-A:same barriers.
By allowin
On Sat, 11 Feb 2012, Raphael Hertzog wrote:
> It could be a source of subtle bugs if this leads to having
> libfoo:i386 (1.0) + libfoo:amd64 (2.0) + libfoo-data:all (2.0)
>
> But then the proper answer is for the maintainer to put
> a tight dependency “Depends: libfoo-data (= ${source:Version})”.
* Joey Hess , 2012-02-10, 22:35:
/usr/share/doc/pkgname/
/usr/share/bug/pkgname
/usr/share/lintian/overrides/pkgname
/usr/share/mime-info/pkgname.*
/usr/share/menu/pkgname
...
(Joey, I'm guessing you might consider it too late to do some of these in
debhelper for compat level 9, righ
Hello,
On Sat, 11 Feb 2012, Jakub Wilk wrote:
> >* Deploying refcnt means that M-A:same packages must always be at
> >the same exact installed version, so that the file contents can
> >match.
> >↓
> >More difficult upgrade paths, as this ties the different arch
> >dependency trees around M-A:same
On Fri, 2012-02-10 at 17:35 -0800, Russ Allbery wrote:
> I think we have to do something saner with changelog files eventually
> regardless, but I'm curious: how did Ubuntu deal with the binNMU problem
> that Guillem identified? If you binNMU a library on amd64 but not on
> i386, as near as I can
Guillem Jover wrote:
> Descriptions are only downloaded once nowadays.
Not actually true; apt-get update downloads all package descriptions
without even pdiffs nowadays, every time there's a change to any
single description.
Get:22 http://ftp.nl.debian.org unstable/main Translation-en [3,882 kB]
Steve Langasek writes:
> On Fri, Feb 10, 2012 at 06:56:00PM -0600, Jonathan Nieder wrote:
>> I agree that the extra work of removing "multi-arch: same" for existing
>> -dev packages that have been converted is a major downside. And on the
>> other hand, the need throughout Debian infrastructure
On Fri, Feb 10, 2012 at 11:56:20PM +0100, Guillem Jover wrote:
> [ Obviously this “summary” could be considered biased, but I do think
> the facts presented are accurate. ]
> The two reasons for the shared / reference counted files (refcnt from
> now on) implementation in dpkg have been:
Well
On Fri, Feb 10, 2012 at 06:56:00PM -0600, Jonathan Nieder wrote:
> Could you elaborate on this?
> As long as dependencies are accurate, I don't see how allowing
> co-installation of the same package for two different architectures at
> different versions is any more complicated than pinned to the
Hi,
Jakub Wilk wrote:
> How about:
> * Because this the obvious and elegant way of doing things. It makes
> multiarchification easy for packagers, and invisible for uses,
> including those users who don't care about multi-arch (unless they
> rely on paths to the libraries, which they never should
* Guillem Jover , 2012-02-10, 23:56:
[ Obviously this “summary” could be considered biased, but I do think
the facts presented are accurate. ]
Well, biased in an euphemism here...
The two reasons for the shared / reference counted files (refcnt from
now on) implementation in dpkg have been:
As the maintainer of a few (popular) library packages I consider
splitting these packages a complex and annoying workaround for
deficiencies in tools.
It is not true that splitting the package is a one time action, every
release which adds new files will require dealing with the split.
Why was
[ Obviously this “summary” could be considered biased, but I do think
the facts presented are accurate. ]
Hi,
The two reasons for the shared / reference counted files (refcnt from
now on) implementation in dpkg have been:
* To avoid massive package proliferation (due to the mandated copyright
45 matches
Mail list logo
