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 |
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 |
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/ |
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/ |
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 |
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 |
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 |
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 |
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 |
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 01:59 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.