Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match) (http://www.linux-archive.org/debian-dpkg/632681-multiarch-file-overlap-summary-proposal-summary-dpkg-shared-reference-counted-files-version-match.html)

Raphael Hertzog 02-14-2012 06:39 AM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
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 for this.

> 2. Files like the above but that are compressed. This is most common in
> the doc directory for things like README or the upstream changelog.
> Upstream man pages written directly in *roff fall into this category as
> well, for -dev packages. With Steve's point above about gzip, I think
> we're probably okay using refcounting for this as well.

Yes, but I would still document at the policy level that, when feasible
without downsides, it's best to move compressed files in a shared package.

Also it might be wise to relax the policy rules on compression for
multi-arch: same and to let dh_compress not compress (some) files in such
packages.

> Does this seem comprehensive to everyone? Am I missing any cases?

It's a good summary, yes.

> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:

I agree with this plan.

> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.

I wonder what's the proper way to handle this. In theory, it would be nice
to deal with that at the dpkg-dev level but dpkg-dev is not at all
involved in installing the changelog. And I believe that the bin-nmu
process just adds a top-level entry to debian/changelog.

So the code should go to dh_installchangelogs... but it doesn't seem to be
a good idea to put the bin-nmu logic there in particular since we might
extend it (see #440094).

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 <binnmu-part-file> <remaining-part-file>

Then dh_installchangelogs could try to use this (and if it fails, fallback
to the standard changelog installation).

Does that sound sane? If yes, I can have a look at implementing this.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120214073923.GA866@rivendell.home.ouaza.com">htt p://lists.debian.org/20120214073923.GA866@rivendell.home.ouaza.com

Raphael Hertzog 02-14-2012 06:39 AM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
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 for this.

> 2. Files like the above but that are compressed. This is most common in
> the doc directory for things like README or the upstream changelog.
> Upstream man pages written directly in *roff fall into this category as
> well, for -dev packages. With Steve's point above about gzip, I think
> we're probably okay using refcounting for this as well.

Yes, but I would still document at the policy level that, when feasible
without downsides, it's best to move compressed files in a shared package.

Also it might be wise to relax the policy rules on compression for
multi-arch: same and to let dh_compress not compress (some) files in such
packages.

> Does this seem comprehensive to everyone? Am I missing any cases?

It's a good summary, yes.

> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:

I agree with this plan.

> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.

I wonder what's the proper way to handle this. In theory, it would be nice
to deal with that at the dpkg-dev level but dpkg-dev is not at all
involved in installing the changelog. And I believe that the bin-nmu
process just adds a top-level entry to debian/changelog.

So the code should go to dh_installchangelogs... but it doesn't seem to be
a good idea to put the bin-nmu logic there in particular since we might
extend it (see #440094).

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 <binnmu-part-file> <remaining-part-file>

Then dh_installchangelogs could try to use this (and if it fails, fallback
to the standard changelog installation).

Does that sound sane? If yes, I can have a look at implementing this.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120214073923.GA866@rivendell.home.ouaza.com">htt p://lists.debian.org/20120214073923.GA866@rivendell.home.ouaza.com

Philipp Kern 02-14-2012 08:12 AM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
On 2012-02-14, Raphael Hertzog <hertzog@debian.org> wrote:
> I wonder what's the proper way to handle this. In theory, it would be nice
> to deal with that at the dpkg-dev level but dpkg-dev is not at all
> involved in installing the changelog. And I believe that the bin-nmu
> process just adds a top-level entry to debian/changelog.
>
> So the code should go to dh_installchangelogs... but it doesn't seem to be
> a good idea to put the bin-nmu logic there in particular since we might
> extend it (see #440094).
>
> 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 <binnmu-part-file> <remaining-part-file>
>
> Then dh_installchangelogs could try to use this (and if it fails, fallback
> to the standard changelog installation).
>
> Does that sound sane? If yes, I can have a look at implementing this.

In theory sbuild could also offload this to dpkg-buildpackage by passing
something like "--binnmu-version 2 --binnmu-changelog 'Rebuild for libfoo
transition'". The only thing that would be annoying is checking if the old
style or the new style must be used. (I.e. there must be some sort of feature
query first.)

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnjjk9br.nqd.trash@kelgar.0x539.de">http://lists.debian.org/slrnjjk9br.nqd.trash@kelgar.0x539.de

Raphael Hertzog 02-14-2012 12:17 PM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
On Tue, 14 Feb 2012, Philipp Kern wrote:
> On 2012-02-14, Raphael Hertzog <hertzog@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 --split-binnmu <binnmu-part-file> <remaining-part-file>
> >
> > Then dh_installchangelogs could try to use this (and if it fails, fallback
> > to the standard changelog installation).
> >
> > Does that sound sane? If yes, I can have a look at implementing this.
>
> In theory sbuild could also offload this to dpkg-buildpackage by passing
> something like "--binnmu-version 2 --binnmu-changelog 'Rebuild for libfoo
> transition'". The only thing that would be annoying is checking if the old
> style or the new style must be used. (I.e. there must be some sort of feature
> query first.)

Yes but that doesn't change anything to the fact that dpkg-dev should not
install files in the generated .deb. So we still need some interaction
with dh_installchangelogs... but your suggestion lead me to another
proposal.

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 debian/changelog so that dpkg-parsechangelog continues to do the
right thing (when called from debian/rules).

And dh_installchangelogs can be taught to install debian/changelog.build
as /usr/share/doc/<foo>/changelog.Debian.build-$arch.

dpkg-buildpackage would clean up debian/changelog.build if it wasn't
passed the proper option. dpkg-source would learn to not include it in
generated source packages, too.

This looks like rather appealing to me. What do you think?

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120214131720.GD11824@rivendell.home.ouaza.com">h ttp://lists.debian.org/20120214131720.GD11824@rivendell.home.ouaza.com

Raphael Hertzog 02-14-2012 12:17 PM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
On Tue, 14 Feb 2012, Philipp Kern wrote:
> On 2012-02-14, Raphael Hertzog <hertzog@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 --split-binnmu <binnmu-part-file> <remaining-part-file>
> >
> > Then dh_installchangelogs could try to use this (and if it fails, fallback
> > to the standard changelog installation).
> >
> > Does that sound sane? If yes, I can have a look at implementing this.
>
> In theory sbuild could also offload this to dpkg-buildpackage by passing
> something like "--binnmu-version 2 --binnmu-changelog 'Rebuild for libfoo
> transition'". The only thing that would be annoying is checking if the old
> style or the new style must be used. (I.e. there must be some sort of feature
> query first.)

Yes but that doesn't change anything to the fact that dpkg-dev should not
install files in the generated .deb. So we still need some interaction
with dh_installchangelogs... but your suggestion lead me to another
proposal.

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 debian/changelog so that dpkg-parsechangelog continues to do the
right thing (when called from debian/rules).

And dh_installchangelogs can be taught to install debian/changelog.build
as /usr/share/doc/<foo>/changelog.Debian.build-$arch.

dpkg-buildpackage would clean up debian/changelog.build if it wasn't
passed the proper option. dpkg-source would learn to not include it in
generated source packages, too.

This looks like rather appealing to me. What do you think?

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120214131720.GD11824@rivendell.home.ouaza.com">h ttp://lists.debian.org/20120214131720.GD11824@rivendell.home.ouaza.com

Ian Jackson 02-14-2012 01:00 PM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
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
> fairly soon, so I think we need to try to drive this discussion to some
> concrete conclusions.

Yes.

> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:

Thanks for this summary and analysis. I agree with your conclusions.

> Does this seem comprehensive to everyone? Am I missing any cases?

I think you have covered all of the cases that have been brought up on
this list, which I think are all of the important and frequent cases.

Thinking about other corner cases can be deferred for now because we
can put off converting affected packages until wheezy+1, or if we
really want to convert we can very probably add a "common" package.
So let us press on.

> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.

If we always put the binNMU changelog file in
/usr/share/doc/<package>/changelog.Debian.<package>:<arch>
then in the symlink case we can put it file in
/usr/share/doc/<symlink-target>/changelog.Debian.<original-package>:<arch>
and everything will work (apart from the fact that some minority of
changelog-reading tools will need to be taught to look at the new path).

> Please note that this is a bunch of work. I think the Lintian work is a
> good idea regardless, and it can start independently. I think the same is
> true of the binNMU changelog work, since this will address some
> long-standing issues with changelog handling in some situations, including
> resolving just how we're supposed to handle /usr/share/doc symlinks. But
> even with those aside, this is a lot of stuff that we need to agree on,
> and in some cases implement, in a fairly short timeline if this is going
> to make wheezy.

Yes. The work that absolutely needs to be done ASAP seems to be:
- put the refcounting back in dpkg
- lintian support for arch-qualified overrides
- update the binNMU machinery to write the new changelog file instead

Things that should be done but are not on the critical paths:
- transpose the restrictions on use of refcounting into policy
(for now they can go in a text file in dpkg-dev, or even just
a reference to your email)
- update changelog-reading tools to look for binNMU changelogs too

Things which we can do at our leisure:
- convert individual libraries
- think about whether to always arch-qualify the whole changelog
- think other refcounting corner cases (see my comments above)

> 5. Data files that vary by architecture. This includes big-endian
> vs. little-endian issues. These are simply incompatible with
> multiarch as currently designed, and incompatible with the obvious
> variations that I can think of, and will have to either be moved
> into arch-qualified directories (with corresponding patches to the
> paths from which the libraries load the data) or these packages
> can't be made multiarch.

Yes. Of these, arch-qualifying the path seem to be to be obviously
the right answer. Of course eg if the data files just come in big-
and little-endian, you can qualify the path with only the endianness
and use refcounting to allow the equal-endianness packages to share.

Ian.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20282.26861.126288.496227@chiark.greenend.org.uk"> http://lists.debian.org/20282.26861.126288.496227@chiark.greenend.org.uk

Ian Jackson 02-14-2012 01:00 PM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
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
> fairly soon, so I think we need to try to drive this discussion to some
> concrete conclusions.

Yes.

> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:

Thanks for this summary and analysis. I agree with your conclusions.

> Does this seem comprehensive to everyone? Am I missing any cases?

I think you have covered all of the cases that have been brought up on
this list, which I think are all of the important and frequent cases.

Thinking about other corner cases can be deferred for now because we
can put off converting affected packages until wheezy+1, or if we
really want to convert we can very probably add a "common" package.
So let us press on.

> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.

If we always put the binNMU changelog file in
/usr/share/doc/<package>/changelog.Debian.<package>:<arch>
then in the symlink case we can put it file in
/usr/share/doc/<symlink-target>/changelog.Debian.<original-package>:<arch>
and everything will work (apart from the fact that some minority of
changelog-reading tools will need to be taught to look at the new path).

> Please note that this is a bunch of work. I think the Lintian work is a
> good idea regardless, and it can start independently. I think the same is
> true of the binNMU changelog work, since this will address some
> long-standing issues with changelog handling in some situations, including
> resolving just how we're supposed to handle /usr/share/doc symlinks. But
> even with those aside, this is a lot of stuff that we need to agree on,
> and in some cases implement, in a fairly short timeline if this is going
> to make wheezy.

Yes. The work that absolutely needs to be done ASAP seems to be:
- put the refcounting back in dpkg
- lintian support for arch-qualified overrides
- update the binNMU machinery to write the new changelog file instead

Things that should be done but are not on the critical paths:
- transpose the restrictions on use of refcounting into policy
(for now they can go in a text file in dpkg-dev, or even just
a reference to your email)
- update changelog-reading tools to look for binNMU changelogs too

Things which we can do at our leisure:
- convert individual libraries
- think about whether to always arch-qualify the whole changelog
- think other refcounting corner cases (see my comments above)

> 5. Data files that vary by architecture. This includes big-endian
> vs. little-endian issues. These are simply incompatible with
> multiarch as currently designed, and incompatible with the obvious
> variations that I can think of, and will have to either be moved
> into arch-qualified directories (with corresponding patches to the
> paths from which the libraries load the data) or these packages
> can't be made multiarch.

Yes. Of these, arch-qualifying the path seem to be to be obviously
the right answer. Of course eg if the data files just come in big-
and little-endian, you can qualify the path with only the endianness
and use refcounting to allow the equal-endianness packages to share.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20282.26861.126288.496227@chiark.greenend.org.uk"> http://lists.debian.org/20282.26861.126288.496227@chiark.greenend.org.uk

Guillem Jover 02-14-2012 01:01 PM

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:
> 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 must only
> contain files in classes 1 and 2 above.
>
> * 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 minor updates of the documentation generation
> tools and when run at different times.

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.

It also requires maintainers to carefully consider if the (doc, etc)
toolchains will generate predictible ouput.

Your proposal still requires papering over the other corner-cases.

> * Policy prohibits arch-varying data files in multiarch: same packages
> except in arch-qualified paths.

Well, there's no escape from this any way you look at it, regardless of
refcnt'ing or not.

> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.

This requires IMO multitude of hacks when the simplest and obvious
arch-qualified pkgname solves this cleanly, and allows debhelper to
automatically deal with it. And for tools to just change where they
always look for those files in the M-A:same case regardless of the
package being binNMUed or not.

This still does not solve the other issues I listed, namely binNMUs
have to be performed in lock-step, more complicated transitions /
upgrades. And introduces different solutions for different problems,
while my proposal is generic for all cases.

So this is still pretty much unconvincing, and seems like clinging
into the refcnt'ing “solution” while it makes things overall more
complicated, will introduce inconsistency and incertainty to
maintainers, needs way more global changes to keep it going, etc.

What I'd change to my proposal in the summary mail, is that arch-indep
files might be considered for splitting at maintainers discretion,
when it actually seems worth it, in the same way we've handled
splitting arch-indep files from arch:any up to now. So for example a
couple of headers could be kept on the -dev package, or Ian's case on
essential and data files could also be kept on the same lib package,
as long as their paths are arch-qualified either trhough a pkgname:arch
or the multiarch triplet. This would reduce even more the amount of
newly split packages.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120214140138.GA23158@gaara.hadrons.org">http://lists.debian.org/20120214140138.GA23158@gaara.hadrons.org

Guillem Jover 02-14-2012 01:01 PM

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:
> 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 must only
> contain files in classes 1 and 2 above.
>
> * 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 minor updates of the documentation generation
> tools and when run at different times.

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.

It also requires maintainers to carefully consider if the (doc, etc)
toolchains will generate predictible ouput.

Your proposal still requires papering over the other corner-cases.

> * Policy prohibits arch-varying data files in multiarch: same packages
> except in arch-qualified paths.

Well, there's no escape from this any way you look at it, regardless of
refcnt'ing or not.

> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.

This requires IMO multitude of hacks when the simplest and obvious
arch-qualified pkgname solves this cleanly, and allows debhelper to
automatically deal with it. And for tools to just change where they
always look for those files in the M-A:same case regardless of the
package being binNMUed or not.

This still does not solve the other issues I listed, namely binNMUs
have to be performed in lock-step, more complicated transitions /
upgrades. And introduces different solutions for different problems,
while my proposal is generic for all cases.

So this is still pretty much unconvincing, and seems like clinging
into the refcnt'ing “solution” while it makes things overall more
complicated, will introduce inconsistency and incertainty to
maintainers, needs way more global changes to keep it going, etc.

What I'd change to my proposal in the summary mail, is that arch-indep
files might be considered for splitting at maintainers discretion,
when it actually seems worth it, in the same way we've handled
splitting arch-indep files from arch:any up to now. So for example a
couple of headers could be kept on the -dev package, or Ian's case on
essential and data files could also be kept on the same lib package,
as long as their paths are arch-qualified either trhough a pkgname:arch
or the multiarch triplet. This would reduce even more the amount of
newly split packages.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120214140138.GA23158@gaara.hadrons.org">http://lists.debian.org/20120214140138.GA23158@gaara.hadrons.org

Ian Jackson 02-14-2012 01:28 PM

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
 
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 file (changelog.Debian.arch, probably). We need to
> > figure out what this means if the package being binNMU'd has a
> > /usr/share/doc/<package> symlink to another package, though; it's not
> > obvious what to do here.
>
> This requires IMO multitude of hacks when the simplest and obvious
> arch-qualified pkgname solves this cleanly, and allows debhelper to
> automatically deal with it. And for tools to just change where they
> always look for those files in the M-A:same case regardless of the
> package being binNMUed or not.

I agree that it would be nice to always arch-qualify the changelog
filename. But that would involve a lot of changes to
changelog-reading tools which we perhaps don't want to do right now.

Note that even if we decide to always arch-qualify, we will still have
lots of old packages so all changelog-reading tools will need to look
in both places.

For most changelog-reading tools it won't be very troublesome if they
accidentally don't spot a binNMU entry. So Russ's proposal is a good
step towards your proposal. And if we decide we don't need to go all
the way then it's good enough for now.

> 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
variation in gzip output ? Given the evidence we've seen here, in
practice I think that is not going to be a problem. Certainly it
won't demand that binNMUs be performed in lock-step.

> So this is still pretty much unconvincing, and seems like clinging
> into the refcnt'ing “solution” while it makes things overall more
> complicated, will introduce inconsistency and incertainty to
> maintainers, needs way more global changes to keep it going, etc.

I think the refcounting approach is very worthwhile because it
eliminates unnecessary work (by human maintainers) in many simple
cases.

Ian.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20282.28586.577528.890135@chiark.greenend.org.uk"> http://lists.debian.org/20282.28586.577528.890135@chiark.greenend.org.uk


All times are GMT. The time now is 05:09 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.