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):
--
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
03-14-2012, 03:43 PM
Sven Joachim
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):
--
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
03-15-2012, 07:02 AM
Raphael Hertzog
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/
03-15-2012, 07:02 AM
Raphael Hertzog
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/
03-18-2012, 01:07 PM
Guillem Jover
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
03-18-2012, 01:07 PM
Guillem Jover
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
03-18-2012, 02:16 PM
"John D. Hendrickson and Sara Darnell"
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
03-18-2012, 02:16 PM
"John D. Hendrickson and Sara Darnell"
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
03-18-2012, 05:31 PM
Jonathan Wiltshire
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
<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
03-19-2012, 06:12 AM
Raphael Hertzog
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
Important information regarding upcoming dpkg 1.16.2 upload
