Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   Important information regarding upcoming dpkg 1.16.2 upload (http://www.linux-archive.org/debian-dpkg/644606-important-information-regarding-upcoming-dpkg-1-16-2-upload.html)

Sven Joachim 03-14-2012 03:43 PM

Important information regarding upcoming dpkg 1.16.2 upload
 
On 2012-03-14 11:33 +0100, Raphael Hertzog wrote:

> On Wed, 14 Mar 2012, Raphael Hertzog wrote:
>> If it outputs nothing on your system, then you're fine. Otherwise
>> it should give you some instructions to follow to bring it back to a
>> coherent state.
>
> There was a bug in the script. An updated version is attached.

Here is a patch adding two missing newlines on output:

--8<---------------cut here---------------start------------->8---
--- cleanup-multiarch.pl~ 2012-03-14 17:30:26.979745054 +0100
+++ cleanup-multiarch.pl 2012-03-14 17:40:14.273052137 +0100
@@ -27,8 +27,8 @@
foreach my $item (@pkgs) {
$pkgarch = $item->{'Package'} . ':' . $item->{'Architecture'};
if ($item->{'Multi-Arch'} ne "same") {
- print "PROBLEM: one instance of $pkg is not Multi-Arch: same";
- print "SOLUTION: dpkg -P $pkgarch";
+ print "PROBLEM: one instance of $pkg is not Multi-Arch: same
";
+ print "SOLUTION: dpkg -P $pkgarch
";
}
}
}
--8<---------------cut here---------------end--------------->8---

> Note that it will list your foreign packages (on INFO: lines)
> but if it outputs nothing else then you're fine. It will print
> lines starting with "PROBLEM: " if it detects something wrong.

It reports a leftover from a failed attempt to crossgrade libc-bin:

,----
| PROBLEM: one instance of libc-bin is not Multi-Arch: same
| SOLUTION: dpkg -P libc-bin:i386
| PROBLEM: one instance of libc-bin is not Multi-Arch: same
| SOLUTION: dpkg -P libc-bin:amd64
`----

Note that libc-bin:amd64 is actually purged, however it remains in the
status file (note that the "Multi-Arch: foreign" field is missing):

,----
| Package: libc-bin
| Status: install ok not-installed
| Priority: required
| Section: libs
| Architecture: amd64
`----

Cheers,
Sven


http://lists.debian.org/debian-dpkg/2011/12/msg00023.html


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877gynqgk1.fsf@turtle.gmx.de">http://lists.debian.org/877gynqgk1.fsf@turtle.gmx.de

Sven Joachim 03-14-2012 03:43 PM

Important information regarding upcoming dpkg 1.16.2 upload
 
On 2012-03-14 11:33 +0100, Raphael Hertzog wrote:

> On Wed, 14 Mar 2012, Raphael Hertzog wrote:
>> If it outputs nothing on your system, then you're fine. Otherwise
>> it should give you some instructions to follow to bring it back to a
>> coherent state.
>
> There was a bug in the script. An updated version is attached.

Here is a patch adding two missing newlines on output:

--8<---------------cut here---------------start------------->8---
--- cleanup-multiarch.pl~ 2012-03-14 17:30:26.979745054 +0100
+++ cleanup-multiarch.pl 2012-03-14 17:40:14.273052137 +0100
@@ -27,8 +27,8 @@
foreach my $item (@pkgs) {
$pkgarch = $item->{'Package'} . ':' . $item->{'Architecture'};
if ($item->{'Multi-Arch'} ne "same") {
- print "PROBLEM: one instance of $pkg is not Multi-Arch: same";
- print "SOLUTION: dpkg -P $pkgarch";
+ print "PROBLEM: one instance of $pkg is not Multi-Arch: same
";
+ print "SOLUTION: dpkg -P $pkgarch
";
}
}
}
--8<---------------cut here---------------end--------------->8---

> Note that it will list your foreign packages (on INFO: lines)
> but if it outputs nothing else then you're fine. It will print
> lines starting with "PROBLEM: " if it detects something wrong.

It reports a leftover from a failed attempt to crossgrade libc-bin:

,----
| PROBLEM: one instance of libc-bin is not Multi-Arch: same
| SOLUTION: dpkg -P libc-bin:i386
| PROBLEM: one instance of libc-bin is not Multi-Arch: same
| SOLUTION: dpkg -P libc-bin:amd64
`----

Note that libc-bin:amd64 is actually purged, however it remains in the
status file (note that the "Multi-Arch: foreign" field is missing):

,----
| Package: libc-bin
| Status: install ok not-installed
| Priority: required
| Section: libs
| Architecture: amd64
`----

Cheers,
Sven


http://lists.debian.org/debian-dpkg/2011/12/msg00023.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877gynqgk1.fsf@turtle.gmx.de">http://lists.debian.org/877gynqgk1.fsf@turtle.gmx.de

Raphael Hertzog 03-15-2012 07:02 AM

Important information regarding upcoming dpkg 1.16.2 upload
 
Hi,

On Wed, 14 Mar 2012, Sven Joachim wrote:
> Here is a patch adding two missing newlines on output:

Thanks.

> Note that libc-bin:amd64 is actually purged, however it remains in the
> status file (note that the "Multi-Arch: foreign" field is missing):

Ok, fixed that as well by ignoring "not-installed" entries when
considering multiple instances. And I kept the advice to dpkg -P only
when it was in config-files state. Otherwise I leave it up to
the user's judgment.

Updated version attached.

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/

Raphael Hertzog 03-15-2012 07:02 AM

Important information regarding upcoming dpkg 1.16.2 upload
 
Hi,

On Wed, 14 Mar 2012, Sven Joachim wrote:
> Here is a patch adding two missing newlines on output:

Thanks.

> Note that libc-bin:amd64 is actually purged, however it remains in the
> status file (note that the "Multi-Arch: foreign" field is missing):

Ok, fixed that as well by ignoring "not-installed" entries when
considering multiple instances. And I kept the advice to dpkg -P only
when it was in config-files state. Otherwise I leave it up to
the user's judgment.

Updated version attached.

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/

Guillem Jover 03-18-2012 01:07 PM

Important information regarding upcoming dpkg 1.16.2 upload
 
Hi,

On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote:
> I'll be uploading dpkg 1.16.2 targeting unstable, by the end of
> this weekend or beginning of next week the latest (after some final
> polishing).

Unfortunately I found some issues with the selection handling and with
dselect and this didn't happen. I'm doing final testing and polishing
now and should be uploading later today, if nothing else comes up...


With multiarch, non-installed selections w/o an architecture, do not
make sense, in addition there's no guarantee they match any entry
from the available file and the db could end up with a selection that
could not be addressed from the command line when other more specific
selections were present. As such the new dpkg will silently drop any
such selections, which look like (with possible Section and Priority
fields):

Package: foo
Status: install ok not-installed

Because those should have been already installed if they were
available, I don't think this should cause any issues, but if you
want to preserve them you'll need to save them before upgrading:

dpkg --get-selection '*' > selections

In addition selections for packages unknown to dpkg will not be
accepted anymore.

> On-disk db damage
> -----------------

> [...], upgrading from those versions to the new dpkg 1.16.2 might
> cause the status db to get messsed up in some conditions. Before
> upgrading, you should either downgrade to a non-multiarch enabled dpkg, or
> make sure there's no package present (i.e. with status >= config-files)
> with a mix of M-A:same and non-M-A:same instances. If there's such package
> with two instances, the new dpkg will consider that a “cross-grade” and
> as such replace one of them with the other, depending on the order they
> are parsed, but leaving any control files untouched; if there's more than
> two instances the new dpkg will outright refuse to parse such bogus and
> inconsistent status db.

I reworked the code to make it more resilient against manual edits of
the status file, which while not a recommended action it might happen
from time to time. As a side effect, this should turn the above issue
into a parsing error, instead of silent lose of information when
upgrading from those dpkg versions.

regards,
guillem


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

Guillem Jover 03-18-2012 01:07 PM

Important information regarding upcoming dpkg 1.16.2 upload
 
Hi,

On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote:
> I'll be uploading dpkg 1.16.2 targeting unstable, by the end of
> this weekend or beginning of next week the latest (after some final
> polishing).

Unfortunately I found some issues with the selection handling and with
dselect and this didn't happen. I'm doing final testing and polishing
now and should be uploading later today, if nothing else comes up...


With multiarch, non-installed selections w/o an architecture, do not
make sense, in addition there's no guarantee they match any entry
from the available file and the db could end up with a selection that
could not be addressed from the command line when other more specific
selections were present. As such the new dpkg will silently drop any
such selections, which look like (with possible Section and Priority
fields):

Package: foo
Status: install ok not-installed

Because those should have been already installed if they were
available, I don't think this should cause any issues, but if you
want to preserve them you'll need to save them before upgrading:

dpkg --get-selection '*' > selections

In addition selections for packages unknown to dpkg will not be
accepted anymore.

> On-disk db damage
> -----------------

> [...], upgrading from those versions to the new dpkg 1.16.2 might
> cause the status db to get messsed up in some conditions. Before
> upgrading, you should either downgrade to a non-multiarch enabled dpkg, or
> make sure there's no package present (i.e. with status >= config-files)
> with a mix of M-A:same and non-M-A:same instances. If there's such package
> with two instances, the new dpkg will consider that a “cross-grade” and
> as such replace one of them with the other, depending on the order they
> are parsed, but leaving any control files untouched; if there's more than
> two instances the new dpkg will outright refuse to parse such bogus and
> inconsistent status db.

I reworked the code to make it more resilient against manual edits of
the status file, which while not a recommended action it might happen
from time to time. As a side effect, this should turn the above issue
into a parsing error, instead of silent lose of information when
upgrading from those dpkg versions.

regards,
guillem


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

"John D. Hendrickson and Sara Darnell" 03-18-2012 02:16 PM

Important information regarding upcoming dpkg 1.16.2 upload
 
Hi, I like dselect, dpkg, and aptitude. I have a request. aptitude should import and export

/var/lib/dpkg/status

At least when asked. Right now aptitude takes awkwardly and but doesn't give back.

It's not just private selections. Private methods and worse pivate status make other programs
impossible.


"aptitude : attempts to detect status of dpkg or dselect" That's is far short of par - noting how
sipmle the task of using human readable status as save format is.


/var/lib/aptitude/pkgstatus

(also it uses pieced avail lists/ instead of unified avail in dpkg/ )

pkgstatus contains incorrect information! and it codes states "1 3 3 4" while using wide text for
everything but that.


My main concern is the these "states" for aptitude are private data - excluding other software - and
covering up why things are wrong. (takeover issues)


Lastly, an end user (me) can make install errors by using aptitude, dpkg, apt-get, dselect not
realizing that aptitude uses privatized unshared current system disk status that isn't what dpkg
uses (and how would you know if it's not in a status file to see?)


There's a way to get aptitude states maybe by relying on dump software. Though relying on anyone
keeping dumpers efficient and up to date simply isn't a great idea.


a more efficient status file (table) is maybe a good idea but using object dumps for system status -
not wise.


Thanks much i enjoy aptitude and dselect both :)

John

http://sourceforge.net/projects/dep-trace

see examples

new ver not yet uploaded show specific depends order of all in status
which it can't do without status [and dpkg --compare-versions]

anohter script has demonstrated it then can use dpkg to , optionally ,
use current status dependancy order as an order to install new packages


On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote:

I'll be uploading dpkg 1.16.2 targeting unstable, by the end of


from the available file and the db could end up with a selection that
could not be addressed from the command line when other more specific
selections were present.

Package: foo
Status: install ok not-installed


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F65FC36.4040709@cox.net">http://lists.debian.org/4F65FC36.4040709@cox.net

"John D. Hendrickson and Sara Darnell" 03-18-2012 02:16 PM

Important information regarding upcoming dpkg 1.16.2 upload
 
Hi, I like dselect, dpkg, and aptitude. I have a request. aptitude should import and export

/var/lib/dpkg/status

At least when asked. Right now aptitude takes awkwardly and but doesn't give back.

It's not just private selections. Private methods and worse pivate status make other programs
impossible.


"aptitude : attempts to detect status of dpkg or dselect" That's is far short of par - noting how
sipmle the task of using human readable status as save format is.


/var/lib/aptitude/pkgstatus

(also it uses pieced avail lists/ instead of unified avail in dpkg/ )

pkgstatus contains incorrect information! and it codes states "1 3 3 4" while using wide text for
everything but that.


My main concern is the these "states" for aptitude are private data - excluding other software - and
covering up why things are wrong. (takeover issues)


Lastly, an end user (me) can make install errors by using aptitude, dpkg, apt-get, dselect not
realizing that aptitude uses privatized unshared current system disk status that isn't what dpkg
uses (and how would you know if it's not in a status file to see?)


There's a way to get aptitude states maybe by relying on dump software. Though relying on anyone
keeping dumpers efficient and up to date simply isn't a great idea.


a more efficient status file (table) is maybe a good idea but using object dumps for system status -
not wise.


Thanks much i enjoy aptitude and dselect both :)

John

http://sourceforge.net/projects/dep-trace

see examples

new ver not yet uploaded show specific depends order of all in status
which it can't do without status [and dpkg --compare-versions]

anohter script has demonstrated it then can use dpkg to , optionally ,
use current status dependancy order as an order to install new packages


On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote:

I'll be uploading dpkg 1.16.2 targeting unstable, by the end of


from the available file and the db could end up with a selection that
could not be addressed from the command line when other more specific
selections were present.

Package: foo
Status: install ok not-installed


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F65FC36.4040709@cox.net">http://lists.debian.org/4F65FC36.4040709@cox.net

Jonathan Wiltshire 03-18-2012 05:31 PM

Important information regarding upcoming dpkg 1.16.2 upload
 
On Sun, Mar 18, 2012 at 10:16:06AM -0500, John D. Hendrickson and Sara Darnell wrote:
> Hi, I like dselect, dpkg, and aptitude. I have a request. aptitude should import and export
>
> /var/lib/dpkg/status
>
> At least when asked. Right now aptitude takes awkwardly and but doesn't give back.

I don't see the relevance of your message to this thread. You should file a
wishlist bug for this kind of request, or start a new thread on -dpkg only.
Either way please avoid cross-posting to -devel for no reason.


--
Jonathan Wiltshire jmw@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51

<directhex> i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120318183138.GB16674@lupin.home.powdarrmonkey.ne t">http://lists.debian.org/20120318183138.GB16674@lupin.home.powdarrmonkey.ne t

Raphael Hertzog 03-19-2012 06:12 AM

Important information regarding upcoming dpkg 1.16.2 upload
 
Hi,

On Sun, 18 Mar 2012, Guillem Jover wrote:
> With multiarch, non-installed selections w/o an architecture, do not
> make sense, in addition there's no guarantee they match any entry
> from the available file and the db could end up with a selection that
> could not be addressed from the command line when other more specific
> selections were present. As such the new dpkg will silently drop any
> such selections, which look like (with possible Section and Priority
> fields):
[...]
> In addition selections for packages unknown to dpkg will not be
> accepted anymore.

I'm not sure I understand this correctly but I'm afraid that this is a
serious regression.

It has always been possible to sort-of "duplicate" a system by doing
"dpkg --get-selections >file" on one computer and running "dpkg
--set-selections <file" on another computer followed by an "apt-get
dselect-upgrade".

This requires that dpkg accepts the selection for packages that it
doesn't know about (but that apt knows).

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: 20120319071208.GC22803@rivendell.home.ouaza.com">h ttp://lists.debian.org/20120319071208.GC22803@rivendell.home.ouaza.com


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.