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 03-02-2011, 01:06 PM
Raphael Hertzog
 
Default Help identify packages that multiarch support will break

[ Bcc to -dpkg for info ]

Hello,

since multiarch support in dpkg is on good track, it's about time to
identify what will break when people start using multiarch packages...

I have started filing a few bugs for some packages where I knew of
the problems but I need your help to identify other possible offenders.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=multiarch;users=debian-dpkg@lists.debian.org

Here's what might create troubles:

1/ Anywhere where the user might specify a package name, he should be able
to specifiy "package:arch" to cope with Multi-Arch: same packages that
can be co-installed (e.g. libc6:i386 and libc6:amd64 on the same
system). Those package names can also appear in outputs of dpkg-query
commands (dpkg -l, dpkg -S, dpkg-query -W).

2/ Any program that parses /var/lib/dpkg/status with the assumption that
there's only one entry with "Package: foo" is wrong. Uniqueness is now
only guaranteed on the tuple (Package, Architecture).

In general parsing the status file should not be done, instead you
should use dpkg-query.

3/ Any program that assumes the current layout of control files
(/var/lib/dpkg/info/<package>.<something>) will be broken (at least for
some packages) since the layout will change to support Multi-Arch: same
packages that can be co-installed.

You should use "dpkg-query --control-path <package> <something>" to
retrieve the path of the file. This has been introduced in dpkg 1.15.4
and is thus in squeeze already.


Do you know packages that will be affected by the above problems? Please
file a bug and usertag it with this command:
$ bts user debian-dpkg@lists.debian.org . usertag $bug + multiarch

Thanks in advance.

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: 20110302140611.GH20023@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110302140611.GH20023@rivendell.home.ouaza.com
 
Old 03-02-2011, 01:06 PM
Raphael Hertzog
 
Default Help identify packages that multiarch support will break

[ Bcc to -dpkg for info ]

Hello,

since multiarch support in dpkg is on good track, it's about time to
identify what will break when people start using multiarch packages...

I have started filing a few bugs for some packages where I knew of
the problems but I need your help to identify other possible offenders.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=multiarch;users=debian-dpkg@lists.debian.org

Here's what might create troubles:

1/ Anywhere where the user might specify a package name, he should be able
to specifiy "package:arch" to cope with Multi-Arch: same packages that
can be co-installed (e.g. libc6:i386 and libc6:amd64 on the same
system). Those package names can also appear in outputs of dpkg-query
commands (dpkg -l, dpkg -S, dpkg-query -W).

2/ Any program that parses /var/lib/dpkg/status with the assumption that
there's only one entry with "Package: foo" is wrong. Uniqueness is now
only guaranteed on the tuple (Package, Architecture).

In general parsing the status file should not be done, instead you
should use dpkg-query.

3/ Any program that assumes the current layout of control files
(/var/lib/dpkg/info/<package>.<something>) will be broken (at least for
some packages) since the layout will change to support Multi-Arch: same
packages that can be co-installed.

You should use "dpkg-query --control-path <package> <something>" to
retrieve the path of the file. This has been introduced in dpkg 1.15.4
and is thus in squeeze already.


Do you know packages that will be affected by the above problems? Please
file a bug and usertag it with this command:
$ bts user debian-dpkg@lists.debian.org . usertag $bug + multiarch

Thanks in advance.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110302140611.GH20023@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110302140611.GH20023@rivendell.home.ouaza.com
 
Old 03-02-2011, 01:06 PM
Raphael Hertzog
 
Default Help identify packages that multiarch support will break

[ Bcc to -dpkg for info ]

Hello,

since multiarch support in dpkg is on good track, it's about time to
identify what will break when people start using multiarch packages...

I have started filing a few bugs for some packages where I knew of
the problems but I need your help to identify other possible offenders.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=multiarch;users=debian-dpkg@lists.debian.org

Here's what might create troubles:

1/ Anywhere where the user might specify a package name, he should be able
to specifiy "package:arch" to cope with Multi-Arch: same packages that
can be co-installed (e.g. libc6:i386 and libc6:amd64 on the same
system). Those package names can also appear in outputs of dpkg-query
commands (dpkg -l, dpkg -S, dpkg-query -W).

2/ Any program that parses /var/lib/dpkg/status with the assumption that
there's only one entry with "Package: foo" is wrong. Uniqueness is now
only guaranteed on the tuple (Package, Architecture).

In general parsing the status file should not be done, instead you
should use dpkg-query.

3/ Any program that assumes the current layout of control files
(/var/lib/dpkg/info/<package>.<something>) will be broken (at least for
some packages) since the layout will change to support Multi-Arch: same
packages that can be co-installed.

You should use "dpkg-query --control-path <package> <something>" to
retrieve the path of the file. This has been introduced in dpkg 1.15.4
and is thus in squeeze already.


Do you know packages that will be affected by the above problems? Please
file a bug and usertag it with this command:
$ bts user debian-dpkg@lists.debian.org . usertag $bug + multiarch

Thanks in advance.

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: 20110302140611.GH20023@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110302140611.GH20023@rivendell.home.ouaza.com
 
Old 03-02-2011, 01:06 PM
Raphael Hertzog
 
Default Help identify packages that multiarch support will break

[ Bcc to -dpkg for info ]

Hello,

since multiarch support in dpkg is on good track, it's about time to
identify what will break when people start using multiarch packages...

I have started filing a few bugs for some packages where I knew of
the problems but I need your help to identify other possible offenders.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=multiarch;users=debian-dpkg@lists.debian.org

Here's what might create troubles:

1/ Anywhere where the user might specify a package name, he should be able
to specifiy "package:arch" to cope with Multi-Arch: same packages that
can be co-installed (e.g. libc6:i386 and libc6:amd64 on the same
system). Those package names can also appear in outputs of dpkg-query
commands (dpkg -l, dpkg -S, dpkg-query -W).

2/ Any program that parses /var/lib/dpkg/status with the assumption that
there's only one entry with "Package: foo" is wrong. Uniqueness is now
only guaranteed on the tuple (Package, Architecture).

In general parsing the status file should not be done, instead you
should use dpkg-query.

3/ Any program that assumes the current layout of control files
(/var/lib/dpkg/info/<package>.<something>) will be broken (at least for
some packages) since the layout will change to support Multi-Arch: same
packages that can be co-installed.

You should use "dpkg-query --control-path <package> <something>" to
retrieve the path of the file. This has been introduced in dpkg 1.15.4
and is thus in squeeze already.


Do you know packages that will be affected by the above problems? Please
file a bug and usertag it with this command:
$ bts user debian-dpkg@lists.debian.org . usertag $bug + multiarch

Thanks in advance.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110302140611.GH20023@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110302140611.GH20023@rivendell.home.ouaza.com
 
Old 03-03-2011, 12:04 PM
Carsten Hey
 
Default Help identify packages that multiarch support will break

* Raphael Hertzog [2011-03-02 15:06 +0100]:
> In general parsing the status file should not be done, instead you
> should use dpkg-query.

Is there any reason for this, except that the format of the status files
will evolve?

> You should use "dpkg-query --control-path <package> <something>" to

Jftr, there is a lot potential for performance improvements in
dpkg-query, some queries can be done way faster even in gawk.


Regards
Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110303130456.GA29205@furrball.stateful.de">http://lists.debian.org/20110303130456.GA29205@furrball.stateful.de
 
Old 03-03-2011, 12:45 PM
Raphael Hertzog
 
Default Help identify packages that multiarch support will break

Hi,

On Thu, 03 Mar 2011, Carsten Hey wrote:
> * Raphael Hertzog [2011-03-02 15:06 +0100]:
> > In general parsing the status file should not be done, instead you
> > should use dpkg-query.
>
> Is there any reason for this, except that the format of the status files
> will evolve?

dpkg-query will automatically respect DPKG_ADMINDIR if it's set (and it's
set in maintainer scripts). (this is a new feature in the upcoming version)

And the status file is not a public interface. It's a file used by dpkg.
If tomorrow dpkg supports an optional SQLite internal database through a
plugin, dpkg-query will continue to work but your access to the status
file will not. (This is unlikely to happen any time soon, but you get the
idea)

> > You should use "dpkg-query --control-path <package> <something>" to
>
> Jftr, there is a lot potential for performance improvements in
> dpkg-query, some queries can be done way faster even in gawk.

JFTR, there are also 300+ bugs in the BTS and we are two active developers
on dpkg.

dpkg-query is rarely used in performance sensitive situation, it's not
really my priority to improve it. But if you want to help, you're welcome.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110303134551.GD11723@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110303134551.GD11723@rivendell.home.ouaza.com
 
Old 03-03-2011, 03:02 PM
Guillem Jover
 
Default Help identify packages that multiarch support will break

Hi!

On Thu, 2011-03-03 at 14:45:51 +0100, Raphael Hertzog wrote:
> On Thu, 03 Mar 2011, Carsten Hey wrote:
> > * Raphael Hertzog [2011-03-02 15:06 +0100]:
> > > In general parsing the status file should not be done, instead you
> > > should use dpkg-query.
> >
> > Is there any reason for this, except that the format of the status files
> > will evolve?
>
> dpkg-query will automatically respect DPKG_ADMINDIR if it's set (and it's
> set in maintainer scripts). (this is a new feature in the upcoming version)
>
> And the status file is not a public interface. It's a file used by dpkg.
> If tomorrow dpkg supports an optional SQLite internal database through a
> plugin, dpkg-query will continue to work but your access to the status
> file will not. (This is unlikely to happen any time soon, but you get the
> idea)

Well, the most important reason is that directly parsing the status file
does not take into account the journal files. So yes, nothing should
really be accessing anything under /var/lib/dpkg, although package
manager frontends can be considered currently grandfathered as there's
no sane interface provided by dpkg yet (read libdpkg) for their use,
and they correctly handle the journal files anyway.

> > > You should use "dpkg-query --control-path <package> <something>" to
> >
> > Jftr, there is a lot potential for performance improvements in
> > dpkg-query, some queries can be done way faster even in gawk.
>
> JFTR, there are also 300+ bugs in the BTS and we are two active developers
> on dpkg.
>
> dpkg-query is rarely used in performance sensitive situation, it's not
> really my priority to improve it. But if you want to help, you're welcome.

That's on my TODO list.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110303160243.GA1226@gaara.hadrons.org">http://lists.debian.org/20110303160243.GA1226@gaara.hadrons.org
 
Old 03-03-2011, 03:08 PM
Guillem Jover
 
Default Help identify packages that multiarch support will break

Hi!

On Wed, 2011-03-02 at 15:06:11 +0100, Raphael Hertzog wrote:
> Here's what might create troubles:

> 3/ Any program that assumes the current layout of control files
> (/var/lib/dpkg/info/<package>.<something>) will be broken (at least for
> some packages) since the layout will change to support Multi-Arch: same
> packages that can be co-installed.
>
> You should use "dpkg-query --control-path <package> <something>" to
> retrieve the path of the file. This has been introduced in dpkg 1.15.4
> and is thus in squeeze already.

An additional clarificaton, --control-path will not show internal
information control files (currently .list and .conffiles), for those
dpkg-query --listfiles or --status should be used instead, anything
else should be considered broken.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110303160836.GB1226@gaara.hadrons.org">http://lists.debian.org/20110303160836.GB1226@gaara.hadrons.org
 
Old 03-03-2011, 03:30 PM
Stefano Zacchiroli
 
Default Help identify packages that multiarch support will break

On Thu, Mar 03, 2011 at 02:45:51PM +0100, Raphael Hertzog wrote:
> And the status file is not a public interface. It's a file used by dpkg.
> If tomorrow dpkg supports an optional SQLite internal database through a
> plugin, dpkg-query will continue to work but your access to the status
> file will not. (This is unlikely to happen any time soon, but you get the
> idea)

Is there a way to ask dpkg-query to dump all the information contained
in /var/lib/dpkg/status without either having to: (1) list all fields
explicitly (using --show + --showformat) or (2) list all package names
(using --status)?

I co-maintain some utilities that parse /var/lib/dpkg/status and I'd be
glad to migrate them to dpkg-query, but both solutions above have
drawbacks. (1) is not future proof and will miss the addition of new
fields unless the utility is updated; (2) has a race condition in asking
the currently installed packages and providing them to --status (beside
being a horrible hack in requiring to list all package names as
arguments). Am I missing something?

Having the ability to pass a package (wildcard) pattern to --show would
be enough to solve this problem.

Do you want a bug report about this?

Thanks to the mighty dpkg maintainers!
Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
 
Old 03-03-2011, 04:20 PM
Guillem Jover
 
Default Help identify packages that multiarch support will break

On Thu, 2011-03-03 at 17:30:42 +0100, Stefano Zacchiroli wrote:
> On Thu, Mar 03, 2011 at 02:45:51PM +0100, Raphael Hertzog wrote:
> > And the status file is not a public interface. It's a file used by dpkg.
> > If tomorrow dpkg supports an optional SQLite internal database through a
> > plugin, dpkg-query will continue to work but your access to the status
> > file will not. (This is unlikely to happen any time soon, but you get the
> > idea)
>
> Is there a way to ask dpkg-query to dump all the information contained
> in /var/lib/dpkg/status without either having to: (1) list all fields
> explicitly (using --show + --showformat)

For each package --status will do the trick, for all packages, yeah
it does not support patterns. I guess adding that would be fine. So
one could do something like: dpkg-query -s '*'.

> or (2) list all package names (using --status)?

Currently something like dpkg-query -l|tr -s ' ' ' '|cut -f2 could
do the trick, altough I could agree it sucks a bit. If --status would
accept patterns that would be nicer.

> Having the ability to pass a package (wildcard) pattern to --show would
> be enough to solve this problem.

> Do you want a bug report about this?

Yes, please.

thanks,
guillem


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

Thread Tools




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

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