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 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
* 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
28 matches
Mail list logo
