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 Development

 
 
LinkBack Thread Tools
 
Old 04-27-2011, 12:53 PM
Julian Andres Klode
 
Default Changing APT to pre-depend on ${shlibs:Depends}

Hi,

I hereby request comments on changing APT to pre-depend on
${shlibsepends}. The reason is simple:

When we upload a new version of APT, depending on a newer
library version (due to new symbols, whatever), and APT gets
unpacked before the library, the system's ability to upgrade is
broken, unless you fix it manually via calls to dpkg.

APT is fairly low in the dependency chain, and the dependencies affected
are libgcc1 and libstdc++6 (in addition to dpkg's pre-depends). As those
are installed on most systems anyway, pre-depending on them should not
introduce many problems.

Unless there are strong objections against this move, I will upload it
tomorrow or on Friday.

=== modified file 'debian/changelog'
--- debian/changelog 2011-04-21 10:18:05 +0000
+++ debian/changelog 2011-04-27 12:43:52 +0000
@@ -7,2 +7,5 @@
- Check power after wait, patch by manuel-soto (LP: #705269)
+ * debian/control:
+ - Move ${shlibsepends} to Pre-Depends, as we do not want APT
+ unpacked if a library is too old and thus break upgrades
* doc/apt-key.8.xml:

=== modified file 'debian/control'
--- debian/control 2011-04-15 12:28:11 +0000
+++ debian/control 2011-04-27 12:42:38 +0000
@@ -15,3 +15,4 @@
Architecture: any
-Depends: ${shlibsepends}, debian-archive-keyring, ${miscepends}, gnupg
+Pre-Depends: ${shlibsepends}
+Depends: debian-archive-keyring, ${miscepends}, gnupg
Replaces: manpages-pl (<< 20060617-3~)

--
Julian Andres Klode - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1303908808.11353.6.camel@jak-thinkpad">http://lists.debian.org/1303908808.11353.6.camel@jak-thinkpad
 
Old 04-27-2011, 01:05 PM
Julian Andres Klode
 
Default Changing APT to pre-depend on ${shlibs:Depends}

On Mi, 2011-04-27 at 14:53 +0200, Julian Andres Klode wrote:
> Hi,
>
> I hereby request comments on changing APT to pre-depend on
> ${shlibsepends}. The reason is simple:
>
> When we upload a new version of APT, depending on a newer
> library version (due to new symbols, whatever), and APT gets
> unpacked before the library, the system's ability to upgrade is
> broken, unless you fix it manually via calls to dpkg.
>
> APT is fairly low in the dependency chain, and the dependencies affected
> are libgcc1 and libstdc++6 (in addition to dpkg's pre-depends). As those
> are installed on most systems anyway, pre-depending on them should not
> introduce many problems.

The complete list of pre-depends that we would have is (on amd64):
libc6 (>= 2.3.4),
libgcc1 (>= 1:4.1.1),
libstdc++6 (>= 4.5),
zlib1g (>= 1:1.2.2.3)
--
Julian Andres Klode - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1303909501.11353.8.camel@jak-thinkpad">http://lists.debian.org/1303909501.11353.8.camel@jak-thinkpad
 
Old 04-27-2011, 04:34 PM
"Eugene V. Lyubimkin"
 
Default Changing APT to pre-depend on ${shlibs:Depends}

Hi,

On 2011-04-27 14:53, Julian Andres Klode wrote:
> I hereby request comments on changing APT to pre-depend on
> ${shlibsepends}.

> When we upload a new version of APT, depending on a newer
> library version (due to new symbols, whatever), and APT gets
> unpacked before the library, the system's ability to upgrade is
> broken, unless you fix it manually via calls to dpkg.

First, this statement is not true because other package managers exist.

Second, why the APT's ability to upgrade is broken under these
conditions? Unless I'm missing something, the upgrade cannot be
started in the middle of another upgrade [1].

And, "I'll upload if there is no strong objection" is probably
void, because Debian policy requires consensus, not a nonexistance of a
strong objection.

I object to this change.

[1] If we count the situation for resuming broken upgrade, there is a
some chance you'll have to call dpkg manually or some hacks
to proceed anyway.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427163435.GA17477@r500-debian">http://lists.debian.org/20110427163435.GA17477@r500-debian
 
Old 04-27-2011, 05:54 PM
Julian Andres Klode
 
Default Changing APT to pre-depend on ${shlibs:Depends}

On Mi, 2011-04-27 at 19:34 +0300, Eugene V. Lyubimkin wrote:
> Hi,
>
> On 2011-04-27 14:53, Julian Andres Klode wrote:
> > I hereby request comments on changing APT to pre-depend on
> > ${shlibsepends}.
>
> > When we upload a new version of APT, depending on a newer
> > library version (due to new symbols, whatever), and APT gets
> > unpacked before the library, the system's ability to upgrade is
> > broken, unless you fix it manually via calls to dpkg.
>
> First, this statement is not true because other package managers exist.
>
> Second, why the APT's ability to upgrade is broken under these
> conditions? Unless I'm missing something, the upgrade cannot be
> started in the middle of another upgrade [1].
The system's ability to upgrade without involving dpkg is broken if a
newer version of APT is unpacked via dpkg.


>
> And, "I'll upload if there is no strong objection" is probably
> void, because Debian policy requires consensus, not a nonexistance of a
> strong objection.
No. We *should* require consensus. The only way to force a change
against the maintainer's will is tech-ctte or a GR. We do not have a
clear decision in the APT team yet, though, as mvo is not here
currently.

>
> I object to this change.
So we'd need one supporter now to speak up in order to get a neutral
level again.

--
Julian Andres Klode - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1303926882.18323.7.camel@jak-thinkpad">http://lists.debian.org/1303926882.18323.7.camel@jak-thinkpad
 
Old 04-27-2011, 06:14 PM
Adam Borowski
 
Default Changing APT to pre-depend on ${shlibs:Depends}

On Wed, Apr 27, 2011 at 07:34:35PM +0300, Eugene V. Lyubimkin wrote:
> On 2011-04-27 14:53, Julian Andres Klode wrote:
> > I hereby request comments on changing APT to pre-depend on
> > ${shlibsepends}.
>
> > When we upload a new version of APT, depending on a newer
> > library version (due to new symbols, whatever), and APT gets
> > unpacked before the library, the system's ability to upgrade is
> > broken, unless you fix it manually via calls to dpkg.
>
> First, this statement is not true because other package managers exist.

You mean, one could manually hunt down and locate a .deb file, wget then
feed it to dpkg? Perhaps the non-apt code paths in dselect have not
bitrotted yet to have a modicum of usability left, but then, you won't find
dselect on any sane system installed this millenium, and to install dselect
to do recovery, you'd need to... right, have usable apt or hunt down .deb
files by hand.

> Second, why the APT's ability to upgrade is broken under these
> conditions?

Because you can't start apt's binary.

> Unless I'm missing something, the upgrade cannot be started in the middle
> of another upgrade.

If an upgrade fails for any reason, including a power failure, you won't be
able to restart apt to let it finish it.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427181447.GA21868@angband.pl">http://lists.debian.org/20110427181447.GA21868@angband.pl
 
Old 04-27-2011, 06:35 PM
"Eugene V. Lyubimkin"
 
Default Changing APT to pre-depend on ${shlibs:Depends}

On 2011-04-27 19:54, Julian Andres Klode wrote:
> > > I hereby request comments on changing APT to pre-depend on
> > > ${shlibsepends}.
> >
> > > When we upload a new version of APT, depending on a newer
> > > library version (due to new symbols, whatever), and APT gets
> > > unpacked before the library, the system's ability to upgrade is
> > > broken, unless you fix it manually via calls to dpkg.
> >
> > First, this statement is not true because other package managers exist.
> >
> > Second, why the APT's ability to upgrade is broken under these
> > conditions? Unless I'm missing something, the upgrade cannot be
> > started in the middle of another upgrade [1].

> The system's ability to upgrade without involving dpkg is broken if a
> newer version of APT is unpacked via dpkg.

Thanks, I read that already above, and that do not (yet) address my two
points.

> > And, "I'll upload if there is no strong objection" is probably
> > void, because Debian policy requires consensus, not a nonexistance of a
> > strong objection.
> No. We *should* require consensus. The only way to force a change
> against the maintainer's will is tech-ctte or a GR. We do not have a
> clear decision in the APT team yet, though, as mvo is not here
> currently.

I wonder what's the point of a discussion then if it has zero effect on
the decision.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427183524.GA20223@r500-debian">http://lists.debian.org/20110427183524.GA20223@r500-debian
 
Old 04-27-2011, 06:45 PM
Henrique de Moraes Holschuh
 
Default Changing APT to pre-depend on ${shlibs:Depends}

On Wed, 27 Apr 2011, Julian Andres Klode wrote:
> I hereby request comments on changing APT to pre-depend on
> ${shlibsepends}. The reason is simple:
>
> When we upload a new version of APT, depending on a newer
> library version (due to new symbols, whatever), and APT gets
> unpacked before the library, the system's ability to upgrade is
> broken, unless you fix it manually via calls to dpkg.
>
> APT is fairly low in the dependency chain, and the dependencies affected
> are libgcc1 and libstdc++6 (in addition to dpkg's pre-depends). As those
> are installed on most systems anyway, pre-depending on them should not
> introduce many problems.
>
> Unless there are strong objections against this move, I will upload it
> tomorrow or on Friday.

Are there any real drawbacks? Would it cause worse behaviour or problems
for the error-rewind paths if either the pre-deps, or apt fails to install,
as compared with the current status-quo?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427184532.GD7102@khazad-dum.debian.net">http://lists.debian.org/20110427184532.GD7102@khazad-dum.debian.net
 
Old 04-27-2011, 06:46 PM
Peter Samuelson
 
Default Changing APT to pre-depend on ${shlibs:Depends}

First, +1 to the Pre-Depends. I think it's well-justified here.

[Eugene V. Lyubimkin]
> Second, why the APT's ability to upgrade is broken under these
> conditions? Unless I'm missing something, the upgrade cannot be
> started in the middle of another upgrade [1].

> [1] If we count the situation for resuming broken upgrade, there is a
> some chance you'll have to call dpkg manually or some hacks
> to proceed anyway.

Not always. There are states dpkg goes through that 'apt-get install'
can "recover" from on its own. You don't always have to go to dpkg.

Also, what if apt wants to call one of its auxilliary binaries during
the install/upgrade? I imagine it's not implemented that way _now_,
but a Pre-Depends would make such a thing a lot safer if they want it.
(Same is true if they want to dlopen a library during the install, but
that's somewhat less likely.)

> I object to this change.

On what grounds? So far we have:

Pro:
- Would make upgrades more robust
- Would make apt implementation more flexible

Con:
- In general, Pre-Depends enforces stricter constraints
- ???

I thought Julian gave a good answer to the issue of the stricter
constraints: apt is quite low on the dependency chain, depending only
on some quite low-level libraries, so the impact should be minimal.

--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427184650.GB20906@p12n.org">http://lists.debian.org/20110427184650.GB20906@p12n.org
 
Old 04-27-2011, 06:54 PM
"Eugene V. Lyubimkin"
 
Default Changing APT to pre-depend on ${shlibs:Depends}

On 2011-04-27 20:14, Adam Borowski wrote:
> > First, this statement is not true because other package managers exist.
>
> You mean, one could manually hunt down and locate a .deb file, wget then
> feed it to dpkg?

Well, yes, one can. I did it once in the past.

But the point was there are other high-level package managers - I know
'cupt' and 'smartpm'.

> Perhaps the non-apt code paths in dselect have not
> bitrotted yet to have a modicum of usability left, but then, you won't find
> dselect on any sane system installed this millenium, and to install dselect
> to do recovery, you'd need to... right, have usable apt or hunt down .deb
> files by hand.

Assumptions 'sane' and 'installed this millenium' are not technical
arguments.

> If an upgrade fails for any reason, including a power failure, you won't be
> able to restart apt to let it finish it.

As you and me pointed already, there are other (hard or easy) ways and
tools to fix the system. APT is not Essential, a system can live without
it.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427185421.GB20223@r500-debian">http://lists.debian.org/20110427185421.GB20223@r500-debian
 
Old 04-27-2011, 07:01 PM
David Kalnischkies
 
Default Changing APT to pre-depend on ${shlibs:Depends}

On Wed, Apr 27, 2011 at 18:34, Eugene V. Lyubimkin <jackyf@debian.org> wrote:
> On 2011-04-27 14:53, Julian Andres Klode wrote:
>> I hereby request comments on changing APT to pre-depend on
>> ${shlibsepends}.
>
>> * * * * When we upload a new version of APT, depending on a newer
>> * * * * library version (due to new symbols, whatever), and APT gets
>> * * * * unpacked before the library, the system's ability to upgrade is
>> * * * * broken, unless you fix it manually via calls to dpkg.
>
> First, this statement is not true because other package managers exist.

Exactly my argument as this would properly be true for synaptic or
update-manager, too, so these should have their dependencies as
pre-depends, too, as a user used to gui will be unable to do it by hand
as much as a user used to APT will be able to do it with dpkg…
And if that is too much over the top i don't want to be the person who
has to decide if cupt, smart, rpm and alike are now in group 1 or 2…

> Second, why the APT's ability to upgrade is broken under these
> conditions? Unless I'm missing something, the upgrade cannot be
> started in the middle of another upgrade [1].

I see two chances for this:
1) unpack apt with dpkg - your problem. A user who is able to install apt
with dpkg should be able to fix it with dpkg. APT is not essential
after all…
2) power loose - you will properly have bigger problems than a maybe
malfunction APT at this point if you will get into this problem at all.

The point Julian has is:
If APT is used to handle his own upgrade it will set itself nearly pseudo-
essential - featuring immediate configuration - so the difference of
this change would be in reality none existent.
But yeah, if it is already done in APT anyway, why forcing
it on dpkg or any other package manager not using APT…

Even without that the current order implementation would properly not
allow the unpack of apt before the unpack of libstdc++ even through
it would be allowed by policy (it would be just silly as it would break
the chance of a working 'dpkg --configure -a' after a power loose or so,
so it would be limited to places it would be impossible to do otherwise).


Best regards

David Kalnischkies

P.S.: The title says RFC not FYI so could we avoid mentioning ctte here?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTinM_07EmvUphni3tLPYM9A4nLrDNw@mail.gmail.com ">http://lists.debian.org/BANLkTinM_07EmvUphni3tLPYM9A4nLrDNw@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 01:19 PM.

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