FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 08-25-2011, 06:19 PM
Julien Cristau
 
Default binNMUs?

On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote:

> Also, I think we still have a reason for +b(something) as sometimes we
> just need to rebuild on a single architecture (because something
> strange has happend there), and I don't want to get rid of that
> ability.
>
The more I think about it, the more I think we should move the binNMU
changelog out of /usr/share/doc and allow co-installation of different
binNMU versions of multi-arch: same packages. (IOW: agreed)

I guess that would need some work in dpkg and sbuild. Anything else
that needs to care about it?

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110825181909.GT2820@radis.liafa.jussieu.fr">http ://lists.debian.org/20110825181909.GT2820@radis.liafa.jussieu.fr
 
Old 09-12-2011, 02:26 PM
Steve Langasek
 
Default binNMUs?

On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote:
> On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote:

> > Also, I think we still have a reason for +b(something) as sometimes we
> > just need to rebuild on a single architecture (because something
> > strange has happend there), and I don't want to get rid of that
> > ability.

> The more I think about it, the more I think we should move the binNMU
> changelog out of /usr/share/doc and allow co-installation of different
> binNMU versions of multi-arch: same packages. (IOW: agreed)

Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I
think /usr/share/doc is still the right place for it, even if it can't be
changelog.Debian.gz anymore.)

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 09-12-2011, 07:19 PM
Andreas Barth
 
Default binNMUs?

* Steve Langasek (vorlon@debian.org) [110912 20:44]:
> On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote:
> > On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote:
>
> > > Also, I think we still have a reason for +b(something) as sometimes we
> > > just need to rebuild on a single architecture (because something
> > > strange has happend there), and I don't want to get rid of that
> > > ability.
>
> > The more I think about it, the more I think we should move the binNMU
> > changelog out of /usr/share/doc and allow co-installation of different
> > binNMU versions of multi-arch: same packages. (IOW: agreed)
>
> Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I
> think /usr/share/doc is still the right place for it, even if it can't be
> changelog.Debian.gz anymore.)

I would rather do /usr/share/doc/$pkg/changelog.$arch.$binNMU - but
well, YMMV. Anyways, I think that dpkg-deb should inject this files
e.g. from an entry in the control file. Otherwise, it might be too
difficult to get this done.


Andi


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110912191929.GG4110@mails.so.argh.org">http://lists.debian.org/20110912191929.GG4110@mails.so.argh.org
 
Old 09-12-2011, 08:33 PM
Julien Cristau
 
Default binNMUs?

On Mon, Sep 12, 2011 at 15:26:16 +0100, Steve Langasek wrote:

> On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote:
> > On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote:
>
> > > Also, I think we still have a reason for +b(something) as sometimes we
> > > just need to rebuild on a single architecture (because something
> > > strange has happend there), and I don't want to get rid of that
> > > ability.
>
> > The more I think about it, the more I think we should move the binNMU
> > changelog out of /usr/share/doc and allow co-installation of different
> > binNMU versions of multi-arch: same packages. (IOW: agreed)
>
> Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I
> think /usr/share/doc is still the right place for it, even if it can't be
> changelog.Debian.gz anymore.)
>
Depends where it's handled, and how the binNMU changelog+version end up
being passed to the build, I think.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110912203301.GC5841@radis.liafa.jussieu.fr">http ://lists.debian.org/20110912203301.GC5841@radis.liafa.jussieu.fr
 
Old 09-15-2011, 06:56 AM
Guillem Jover
 
Default binNMUs?

Hi!

On Mon, 2011-09-12 at 21:19:29 +0200, Andreas Barth wrote:
> * Steve Langasek (vorlon@debian.org) [110912 20:44]:
> > On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote:
> > > On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote:
> > > > Also, I think we still have a reason for +b(something) as sometimes we
> > > > just need to rebuild on a single architecture (because something
> > > > strange has happend there), and I don't want to get rid of that
> > > > ability.
> >
> > > The more I think about it, the more I think we should move the binNMU
> > > changelog out of /usr/share/doc and allow co-installation of different
> > > binNMU versions of multi-arch: same packages. (IOW: agreed)
> >
> > Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I
> > think /usr/share/doc is still the right place for it, even if it can't be
> > changelog.Debian.gz anymore.)
>
> I would rather do /usr/share/doc/$pkg/changelog.$arch.$binNMU - but
> well, YMMV. Anyways, I think that dpkg-deb should inject this files
> e.g. from an entry in the control file. Otherwise, it might be too
> difficult to get this done.

I'm not sure I follow. Do you mean this file would only contain the
binNMU revision changelog entry, or that it would append it to the
source changelog and move it to that new path, or both would be
installed alongside (or maybe something else)? And the binary control
field would get that field added how?

In any case this looks rather ugly, and implies dpkg-deb has to start
changing the contents before build, which is something I've said
before (in others contexts) I don't want to see it start doing. That
would imply dpkg-deb needs to know about packaging policy decision,
and file system layout, etc. The most it should do is verify the
control member for things it knows about.

What comes to mind, even if slightly radical, is that the Debian
changelog file makes more sense as being part of the .deb control
member, and as such end up under the dpkg database. Which would
elegantly solve the co-installability problem, and would allow for
stuff like “dpkg --changelog foo” or “dpkg-deb --changelog foo.deb”
to work reliably (similar to the rpm counterparts).

At least that would make its access uniform (after the transition
period has ended), compared to diverging paths depending on the
package being multiarch + binNMUed, etc. Both of which break current
path assumptions anyways.

And lastly, whatever solution, the problematic packages are multiarch
enabled ones, which have needed manual modifications, so they can as
well still be modified to catter for any change in handling the
changelog.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110915065636.GA17591@gaara.hadrons.org">http://lists.debian.org/20110915065636.GA17591@gaara.hadrons.org
 
Old 09-15-2011, 12:29 PM
Raphael Hertzog
 
Default binNMUs?

Hi,

On Thu, 15 Sep 2011, Guillem Jover wrote:
> I'm not sure I follow. Do you mean this file would only contain the
> binNMU revision changelog entry, or that it would append it to the
> source changelog and move it to that new path, or both would be
> installed alongside (or maybe something else)? And the binary control
> field would get that field added how?

I think the various people who participated in the discussion did not
mean the same thing... :-)

> In any case this looks rather ugly, and implies dpkg-deb has to start
> changing the contents before build, which is something I've said
> before (in others contexts) I don't want to see it start doing. That
> would imply dpkg-deb needs to know about packaging policy decision,
> and file system layout, etc. The most it should do is verify the
> control member for things it knows about.

I agree that dpkg-deb should have nothing to do for this specific case.

I have suggested that the binnmu changelog (which is a single line, or
could easily be constrained to a single line) should just become a new
control header so that the changelog can be installed unmodified. This
could be injected by dpkg-gencontrol based on some information provided
by dpkg-buildpackage (likely a specific environment variable).

The version number to use for the binary packages would be also
dynamically generated by appending some extension to the version
number seen in debian/changelog. This would even allow to use
something else than +bX for bin-nmu which is desirable for many
other usages (backports, PPA, etc.).

> What comes to mind, even if slightly radical, is that the Debian
> changelog file makes more sense as being part of the .deb control
> member, and as such end up under the dpkg database. Which would
> elegantly solve the co-installability problem, and would allow for
> stuff like “dpkg --changelog foo” or “dpkg-deb --changelog foo.deb”
> to work reliably (similar to the rpm counterparts).

While this sounds nice, I don't like the cost it imposes on all dpkg
runs... the info directory is scanned frequently and adding files that
don't have to be there is not a good idea IMO.

Also some packages are providing the changelog in a -common package
to avoid its duplication, and this change would not allow something like
this without some special handling.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110915122900.GB3826@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110915122900.GB3826@rivendell.home.ouaza.com
 
Old 11-02-2011, 01:25 AM
Guillem Jover
 
Default binNMUs?

On Thu, 2011-09-15 at 14:29:00 +0200, Raphael Hertzog wrote:
> I have suggested that the binnmu changelog (which is a single line, or
> could easily be constrained to a single line) should just become a new
> control header so that the changelog can be installed unmodified. This
> could be injected by dpkg-gencontrol based on some information provided
> by dpkg-buildpackage (likely a specific environment variable).

> The version number to use for the binary packages would be also
> dynamically generated by appending some extension to the version
> number seen in debian/changelog. This would even allow to use
> something else than +bX for bin-nmu which is desirable for many
> other usages (backports, PPA, etc.).

These look like hacks to me.

> On Thu, 15 Sep 2011, Guillem Jover wrote:
> > What comes to mind, even if slightly radical, is that the Debian
> > changelog file makes more sense as being part of the .deb control
> > member, and as such end up under the dpkg database. Which would
> > elegantly solve the co-installability problem, and would allow for
> > stuff like “dpkg --changelog foo” or “dpkg-deb --changelog foo.deb”
> > to work reliably (similar to the rpm counterparts).
>
> While this sounds nice, I don't like the cost it imposes on all dpkg
> runs... the info directory is scanned frequently and adding files that
> don't have to be there is not a good idea IMO.

While the way the infodb is currently scanned to select pkg specific
control files is not optimal, the cost of this operation (even with
an increase in the number of files) is not significant and as such is
a non-issue. It's just reading few disk blocks (if at all), and doing
string comparisons.

But regardless, that does not seem a valid concern, *if* for whatever
reason there was some noticable cost, then the correct course of
action is to fix dpkg to use a more optimal infodb layout (like
poolizing it, which has crossed my mind already several times).

> Also some packages are providing the changelog in a -common package
> to avoid its duplication, and this change would not allow something like
> this without some special handling.

There's no special casing needed at all, what would happen would be
that a hardlink is created based on the source package name (as long
as they are the same). This also would give the immediate benefit of
reducing huge duplicated changelog and copyright files, for free (as
in no packager action required), while in addition complying to the
letter on each binary package ships with a proper copyright file. If
OTOH it would be decided we really want to keep not shipping those
files in some binary packages then symlinks could be created when
those are missing.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111102022539.GC13769@gaara.hadrons.org">http://lists.debian.org/20111102022539.GC13769@gaara.hadrons.org
 
Old 11-02-2011, 06:18 AM
Raphael Hertzog
 
Default binNMUs?

On Wed, 02 Nov 2011, Guillem Jover wrote:
> On Thu, 2011-09-15 at 14:29:00 +0200, Raphael Hertzog wrote:
> > I have suggested that the binnmu changelog (which is a single line, or
> > could easily be constrained to a single line) should just become a new
> > control header so that the changelog can be installed unmodified. This
> > could be injected by dpkg-gencontrol based on some information provided
> > by dpkg-buildpackage (likely a specific environment variable).
> >·
> > The version number to use for the binary packages would be also
> > dynamically generated by appending some extension to the version
> > number seen in debian/changelog. This would even allow to use
> > something else than +bX for bin-nmu which is desirable for many
> > other usages (backports, PPA, etc.).
>
> These look like hacks to me.

For me it's the current bin-nmu support with special casing in the
subsvars generation code that seems a hack to me.

Designing a new interface to specify a "binary build version" that differs
from the source version seems like something really useful. The details
do not need to be precisely the one I presented above. But I would very
much like have a clean solution where we get rid of the +bX being the
only possible extension for bin-nmus.

(And really I can't respond to "these look like hacks" if you don't give
more details to what you consider "hackish"...)

> > Also some packages are providing the changelog in a -common package
> > to avoid its duplication, and this change would not allow something like
> > this without some special handling.
>
> There's no special casing needed at all, what would happen would be
> that a hardlink is created based on the source package name (as long
> as they are the same). This also would give the immediate benefit of
> reducing huge duplicated changelog and copyright files, for free (as
> in no packager action required), while in addition complying to the
> letter on each binary package ships with a proper copyright file.

There's also the fact that up to now you can avoid installing the
changelog with --path-exclude and if it becomes part of the control files,
you need a new solution to make the space saving...

> If OTOH it would be decided we really want to keep not shipping those
> files in some binary packages then symlinks could be created when
> those are missing.

Pointing to what?

It seems to be a bad idea to mix the source package namespace and the
binary package namespace in the infodb. So I don't really like your
suggestion to have a reference copy of the file based on the source
package name.

We already had pathological cases where a binary package foo was not built
by the source package foo. Even if we prefix those files with "src:"
to avoid the collision, we're introducing the notion of source package
at a level that should really only care of the binary packages.

OTOH, this is also partly required if we want to allow co-installation of
M-A: same packages with different binary versions but the same source
version... (the difference being that in the former the source package
name matters and in the latter it's the source version that matters)

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111102071820.GB1708@rivendell.home.ouaza.com">ht tp://lists.debian.org/20111102071820.GB1708@rivendell.home.ouaza.com
 

Thread Tools




All times are GMT. The time now is 02:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org