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
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
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
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
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
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, 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
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)
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
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
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
14 matches
Mail list logo
