Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120319071208.gc22...@rivendell.home.ouaza.com
Re: Important information regarding upcoming dpkg 1.16.2 upload
On Mon, 2012-03-19 at 08:12:08 +0100, Raphael Hertzog wrote: 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). Which has always been wrong, it's the equivalent of expecting apt to accept operations on unknown packages. dpkg should really not accept random junk on --set-selections. The implication of this is just that if the available file is not getting updated, then it needs get synced back before setting the selections with one of the several methods: dselect update sync-available apt-cache dumpavail dpkg --update-avail / --merge-avail I don't see how that's too onerous, for a more reliable operation. In addition the users will get a nice warning for unavailable packages. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120319083527.ga4...@gaara.hadrons.org
Re: Important information regarding upcoming dpkg 1.16.2 upload
Guillem Jover writes (Re: Important information regarding upcoming dpkg 1.16.2 upload): On Mon, 2012-03-19 at 08:12:08 +0100, Raphael Hertzog wrote: 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). Which has always been wrong, it's the equivalent of expecting apt to accept operations on unknown packages. dpkg should really not accept random junk on --set-selections. The implication of this is just that if the available file is not getting updated, then it needs get synced back before setting the selections with one of the several methods: No, it is entirely correct (in dpkg's model) for dpkg to accept such settings. If you are using an access method that doesn't involve apt, it will be effective, in that when the packages which were previously selected are presented to dpkg for possible installation, dpkg will know that they're wanted. Ian. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20327.16798.449074.181...@chiark.greenend.org.uk
Re: dpkg, aptitude and use of state files (was: Re: Important information regarding upcoming dpkg 1.16.2 upload)
That's good yes. Sure I'd like info of states differences between (dpkg / dselect) and aptitude and who wouldn't :) I realize it's no where near easy to make dump filters as saying it. Thank you -- John Daniel Hartwig wrote: snip -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f67684b.2040...@cox.net
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120318140726.ga18...@gaara.hadrons.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f65fc36.4040...@cox.net
dpkg, aptitude and use of state files (was: Re: Important information regarding upcoming dpkg 1.16.2 upload)
TL;DR: aptitude does keep dpkg/status and apt/extended_states up-to-date with the *current* state of a package, just like other software. Please do not grok pkgstates to determine if something is installed, etc. On 18 March 2012 23:16, John D. Hendrickson and Sara Darnell johnandsa...@cox.net 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. 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. The developer explains (vaguely) why there is not a one-to-one corelation between dpkg status, aptitude pkgstates, and apt extended_states:[1] Currently, aptitude stores the held status of packages in some internal database. I am guessing this may be /var/lib/aptitude/pkgstates. Would it not be best if it behaved like apt-get, ie. reading information from /var/lib/dpkg/status? No, it wouldn't. dselect's states are not in general equivalent to aptitude's, although they're similar. Not sure what that means? Me either, initially. Aptitude allows the user to mark package changes but leave them for another session. So, interactively you can mark several installs, removals, etc. and then quit, when you start again those changes will still be remembered and ready to perform. This is what it tries to store in pkgstates, the user's intended state for the package, not it's actual state. Except for hold (which is a whole bag of fish), the actual, current state of packages is kept in dpkg and apt files, just like other programs use. 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?) As above, most of pkgstates is actually private to aptitude. Some of it is duplicated for convenience, however, aptitude does take measures to keep in sync. with dpkg/apt when it is started. Admitedly, this process fails quite often. For example, removing a package with apt-get can lead to aptitude trying to reinstall that package. Note that aptitude is aware that the package has been removed, it just mistakenly believes the user has requested it be installed again. 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. I don't think it would be useful for an other program to grok pkgstates to determine if something is installed, etc. Please use the normal dpkg and apt means for that. In theory, the only unique information in pkgstates is whether the user has pending actions marked in aptitude. Any problem in this situation is due entirely to aptitude's unique requirements. IMO the current dpkg and apt status files are quite adequate for those systems. Please be aware that it is my next priority to resolve the issues in this area. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137771#23 Regards -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAN3veReMaYNHWsBfuLO9brNuQ56xoR1uTPkddg=y5lzvzev...@mail.gmail.com
Re: 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/
#!/usr/bin/perl
use Dpkg::Control;
use Dpkg::Index;
my $arch = `dpkg --print-architecture`;
chomp($arch);
my $status = Dpkg::Index-new(type = CTRL_FILE_STATUS);
$status-load(/var/lib/dpkg/status);
sub find_foreign {
my $a = shift;
return ($a ne $arch and $a ne all);
}
sub find_installed {
return ($_[0] !~ / not-installed$/);
}
# Detect multiple instances which are not M-A: same
foreach my $foreign ($status-get(Architecture = \find_foreign)) {
my $pkg = $foreign-{'Package'};
my $pkgarch = $foreign-{'Package'} . ':' . $foreign-{'Architecture'};
my $ma = $foreign-{'Multi-Arch'} || 'no';
print INFO: Foreign package detected: $pkgarch (Multi-Arch: $ma)\n;
my @pkgs = $status-get(Package = $pkg, Status = \find_installed);
if (scalar(@pkgs) 1) {
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\n;
if ($item-{'Status'} =~ / config-files$/) {
print SOLUTION: dpkg -P $pkgarch\n;
} else {
print SOLUTION: update $pkgarch to a good version or get rid of it\n;
}
}
}
}
}
# Find broken packages
foreach my $pkg ($status-get()) {
my $ma = $pkg-{'Multi-Arch'} || '';
next if ($pkg-{'Status'} =~ m/ not-installed$/);
my $pkgarch = $pkg-{'Package'};
if ($ma eq same) {
$pkgarch = $pkg-{'Package'} . ':' . $pkg-{'Architecture'};
}
if (! -e /var/lib/dpkg/info/$pkgarch.list) {
print PROBLEM: $pkgarch has missing info files\n;
print SOLUTION: apt-get --reinstall install $pkgarch\n;
}
}
Re: Important information regarding upcoming dpkg 1.16.2 upload
Hello,
For people who have been playing with multiarch and are scared by
Guillem's (uncoordinated) announce, I have written a small script
to detect whether you have been affected by one of the theoretical
problems that Guillem diagnosed (you only need libdpkg-perl and perl).
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.
On Sat, 10 Mar 2012, Guillem Jover wrote:
With those dpkg versions, when installing a M-A:same instance of
package P arch A, when a previous non-M-A:same version of package P
arch B was present in a config-files state, the installation would
incorrectly remove the control files on the infodb for the arch B
instance. You should check for any packages in the status db w/o
matching files under /var/lib/dpkg/info/.
The script checks for this but dpkg would already output a warning
anyway (files list file for package `%.250s' missing, assuming
package has no files currently installed.).
Another effect of the bogus in-core db layout affected the disappearing
logic, so if you have been running any such dpkg versions, you should
also check in the logs that no package has been improperly disappeared,
although the installed files should still be present.
I don't check this but dpkg prints an explicit message about disappearance
of packages and AFAIK a normal apt-get upgrade should never trigger the
case where a package can be improperly disappeared. It was only seen when
trying to replace a package by its foreign counterpart which was not
really allowed in the first place.
Checking your dpkg logs doesn't hurt though.
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.
The script verifies that any package with multiple instances are correctly
marked as Multi-Arch: same.
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/
#!/usr/bin/perl
use Dpkg::Control;
use Dpkg::Index;
my $arch = `dpkg --print-architecture`;
chomp($arch);
my $status = Dpkg::Index-new(type = CTRL_FILE_STATUS);
$status-load(/var/lib/dpkg/status);
sub find_foreign {
my $a = shift;
return ($a ne $arch and $a ne all);
}
# Detect multiple instances which are not M-A: same
foreach my $foreign ($status-get(Architecture = find_foreign)) {
my $pkg = $foreign-{'Package'};
my $pkgarch = $foreign-{'Package'} . ':' . $foreign-{'Architecture'};
my $ma = $foreign-{'Multi-Arch'};
print INFO: Foreign package detected: $pkgarch (Multi-Arch: $ma)\n;
my @pkgs = $status-get(Package = $pkg);
if (scalar(@pkgs) 1) {
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;
}
}
}
}
# Find broken packages
foreach my $pkg ($status-get()) {
my $ma = $pkg-{'Multi-Arch'} || '';
next if ($pkg-{'Status'} =~ m/ not-installed$/);
my $pkgarch = $pkg-{'Package'};
if ($ma eq same) {
$pkgarch = $pkg-{'Package'} . ':' . $pkg-{'Architecture'};
}
if (! -e /var/lib/dpkg/info/$pkgarch.list) {
print PROBLEM: $pkgarch has missing info files\n;
print SOLUTION: apt-get --reinstall install $pkgarch\n;
}
}
Re: Important information regarding upcoming dpkg 1.16.2 upload
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.
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.
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/
#!/usr/bin/perl
use Dpkg::Control;
use Dpkg::Index;
my $arch = `dpkg --print-architecture`;
chomp($arch);
my $status = Dpkg::Index-new(type = CTRL_FILE_STATUS);
$status-load(/var/lib/dpkg/status);
sub find_foreign {
my $a = shift;
return ($a ne $arch and $a ne all);
}
# Detect multiple instances which are not M-A: same
foreach my $foreign ($status-get(Architecture = \find_foreign)) {
my $pkg = $foreign-{'Package'};
my $pkgarch = $foreign-{'Package'} . ':' . $foreign-{'Architecture'};
my $ma = $foreign-{'Multi-Arch'} || 'no';
print INFO: Foreign package detected: $pkgarch (Multi-Arch: $ma)\n;
my @pkgs = $status-get(Package = $pkg);
if (scalar(@pkgs) 1) {
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;
}
}
}
}
# Find broken packages
foreach my $pkg ($status-get()) {
my $ma = $pkg-{'Multi-Arch'} || '';
next if ($pkg-{'Status'} =~ m/ not-installed$/);
my $pkgarch = $pkg-{'Package'};
if ($ma eq same) {
$pkgarch = $pkg-{'Package'} . ':' . $pkg-{'Architecture'};
}
if (! -e /var/lib/dpkg/info/$pkgarch.list) {
print PROBLEM: $pkgarch has missing info files\n;
print SOLUTION: apt-get --reinstall install $pkgarch\n;
}
}
Re: 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.pl2012-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\n;
+ print SOLUTION: dpkg -P $pkgarch\n;
}
}
}
--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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gynqgk1@turtle.gmx.de
Re: Upcoming dpkg 1.16.2 upload
Quoting Guillem Jover (guil...@debian.org): On the other hand I've also become disappointed after possibly realizing that Debian's culture seems to have been shifting into something different than what it was when I joined, where technical excellence seems to be less important than rushing things out, patience is not considered an important virtue anymore, but being pushy and demanding are, etc. Which means I've been and will be reconsidering what my involvment in the project should be. I'm not sure that this list is the right place for that discussion, but I see too much generalization in this statement. From what I've witnessed, the apparent rush has been quite soft and most people involved in this multi-arch stuff much more deeply than I am have refrained from pushing things too hard for a very long time before becoming more insisting (and I think it wouldn't be fair to translate people to Raphaël, here). A *lot* of care has been taken to respect your very obvious commitment to technical excellence and will to do the right thing and I don't think that the TC people fit the definition you give above. I think that everybody agrees that multi-arch changes are, in some way, risky changes and this, particularly in the core package that dpkg is. But I also think that, after a few weeks, we see that we needed that release to unveil all consequences that, indeed, no human could anticipate. Nobody wants to repeat the 3-year release cycle of sarge, I'm afraid. I'm sure this won't convince you more than you are now, but I also think it's really unfair to conclude that the Debian culture has changed because of that. And, frankly, from what I have witnessed over the years, we already had many disruptive innovations happening in our core packages in that past and probably not all of them were as prepared as the multi-arch thing has been Again, I think that some words had to be said about all this and, as I can't speak about technical issues that are flying miles over my headI then focus on the social issues. Nobody can't really prevent me from doing so..:-) So, well, in short, keep up with the good work and please don't give up...neither now or in a near future. signature.asc Description: Digital signature
Re: Upcoming dpkg 1.16.2 upload
Thank you Christian, My opion is ... As to new developers rushing? Mark pkgs as conflicts or alpha / beta and major minor versions correctly and you are fine :) a much bigger / free-er to submit contrib/ section would be nice. I DEFINITELY have the option (1) DMs and DDs are PREVENTING new submissions (contrib/ wise) with too many rules and this frustrates fresh meat. (2) but at the same time they are allowing massive breaking by ignoring to force use conflicts/alpha beta/major version bump where it belongs. (ie, i copy from host a new lib same major version and stuff not requiring minor improvements breaks) My feeling? If a new stable isn't? People will use the old stable until it is good. In general it's gotten better and more and better pkgs than ever are running. Way better than buzz and with allot more hardware challenges to overcome ! :) Thanks all --John Christian PERRIER wrote: snip bubu...@debian.org -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f523079.4040...@cox.net
Re: Upcoming dpkg 1.16.2 upload
Guillem Jover guil...@debian.org writes: On the other hand I've also become disappointed after possibly realizing that Debian's culture seems to have been shifting into something different than what it was when I joined, where technical excellence seems to be less important than rushing things out, patience is not considered an important virtue anymore, but being pushy and demanding are, etc. Which means I've been and will be reconsidering what my involvment in the project should be. You are kind of implying that you are the only one with technical excellence and that all the people that designed, wrote and send you multiarch stuff do not. It saddens me too that Debian's culture seem to have changed to where a single person things he has the only technical excellence on a subject. Please do not quit but maybe stop putting it all on just your shoulders. There must be someone else out there that you consider to have sufficient technical experteese to work with you. And if not then it would be even more important to bring someone else up to code. Having such a central component as dpkg rely on just one person is a disaster and the 10 month delay to review the multiarch patches will be the least of the problems over time. Say next year you do quit or something happens to you where would dpkg and Debian stand then. MfG Goswin PS: having someone else on the team can also mean you can offload more stuff you don't like on them and do more of the stuff you do like in dpkg. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eht8khu4.fsf@frosties.localnet
Re: Upcoming dpkg 1.16.2 upload
On Wed, 2012-02-29 at 06:53:10 +0100, Christian PERRIER wrote: Quoting Guillem Jover (guil...@debian.org): Despite the circumstances, I've still managed to find some motivation to work on finishing reviewing and fixing code. Last week I got the I found really great that even while you were (from your POV) forced to have dpkg uploaded to unstable while you disagreed with the upload, you didn't take this as a personal attack and continued to work on the package. This is a really difficult decision to take: it's much more easy to say that such things shouldn't be taken personnally than really apply this concept and not take things as personal. Well, I'm sorry to disappoint then, but I've not taken it gracefully, and my possible lack of a more visceral reaction, does not imply I'm not even more annoyed than I've been during the past last year. The thing is, the fact that I've found the multiarch branch technically unnacceptable for merge (some people seem to think I've been “stalling” for no reason...), does not change even if people who have apparently not even reviewed the code claim so, and as such anything I've found broken or bogus about it, I'll keep finding that way and will keep having the urge to eventually fix, not doing so would imply I'm not taking proper care of dpkg, at which point I might as well quit (which has already crossed my mind), or more likely continue hacking on the code elsewhere (because that's the remaining part I'm actually still enjoying). On the other hand I've also become disappointed after possibly realizing that Debian's culture seems to have been shifting into something different than what it was when I joined, where technical excellence seems to be less important than rushing things out, patience is not considered an important virtue anymore, but being pushy and demanding are, etc. Which means I've been and will be reconsidering what my involvment in the project should be. [...] and I really hope that the difficult times we had are now over. Sadly, given the current environment and fundamental philosophical and working style incompatibilities, I doubt that... regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120303034124.ga7...@gaara.hadrons.org
Re: Upcoming dpkg 1.16.2 upload
Hi, On Wed, 29 Feb 2012, Guillem Jover wrote: Despite the circumstances, I've still managed to find some motivation to work on finishing reviewing and fixing code. Thanks for this! Last week I got the bulk of the stuff done, input interfaces, correct in-core db layout, cross-grading working and other buggy stuff fixed, with the accompanying functional test-suite cleaned up and adapted too. 1/ Have you kept reference counting of shared files? The consensus on -devel seemed that it was worth keeping it. 2/ Can you push your work in progress on pu/multiarch/master like you used to do? I'll be doing final polish and pushes during this week, and expect to be able to do an upload by the mid/end of next week. \o/ 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229110756.gb18...@rivendell.home.ouaza.com
Upcoming dpkg 1.16.2 upload
Hi, Despite the circumstances, I've still managed to find some motivation to work on finishing reviewing and fixing code. Last week I got the bulk of the stuff done, input interfaces, correct in-core db layout, cross-grading working and other buggy stuff fixed, with the accompanying functional test-suite cleaned up and adapted too. I'll be doing final polish and pushes during this week, and expect to be able to do an upload by the mid/end of next week. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229001505.ga2...@gaara.hadrons.org
Re: Upcoming dpkg 1.16.2 upload
Quoting Guillem Jover (guil...@debian.org): Hi, Despite the circumstances, I've still managed to find some motivation to work on finishing reviewing and fixing code. Last week I got the This is something I wanted to put in light, indeed (with your permission, I'd like to blog about this). I found really great that even while you were (from your POV) forced to have dpkg uploaded to unstable while you disagreed with the upload, you didn't take this as a personal attack and continued to work on the package. This is a really difficult decision to take: it's much more easy to say that such things shouldn't be taken personnally than really apply this concept and not take things as personal. During recent weeks, I witnessed your continued activity on dpkg, Guillem, and I'm admirative of this. And your proposal to upload a new version is a confirmation of this feeling. Keep up with the good work and I really hope that the difficult times we had are now over. So, at least in my own name, I'd like to thank you for this. signature.asc Description: Digital signature
