[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Changing APT to pre-depend on ${shlibs:Depends}



On Thu, Apr 28, 2011 at 04:55, Peter Samuelson <peter@p12n.org> wrote:
>> As discussed elsewhere in this thread, anyone relying on apt for
>> upgrades would be using apt to upgrade apt, so an alternative to
>> consider would be making apt fake the pre-depends internally.
>
> Is it feasible for apt to fake the pre-depends even when it's being
> used as a backend to, e.g., aptitude?  I have no idea.  Sounds
> complicated, anyway.

We don't need to implement it as it is already implemented -
for ages, if i look up the history correctly since February 1999…
(in the same cvs-to-arch converted commit 263 APT's priority is
 promoted from optional to standard btw)

I am a bit worried to call it a two-line change, but as this flag
it sets on itself is called Important and all pseudo essential packages
will get this flag later, too, which causes the immediate configuration
it really is if we count lines here…
(and yes, it effects all applications using APT as long as they do not
 parse Packages files by hand which hopefully nobody does -
 not that i would be completely surprised through… ;) )

Immediate configuration means that APT will configure a package
immediately after it has unpacked the package - what is needed to
configure an unpacked package? You nailed it…
So basically APTs Depends are already Pre-Depends for APT itself…

Making it "real" has therefore no benefits for APT directly.
It makes it "just" a tiny bit harder for dpkg if you install by hand,
for debootstrap to create buildd and above, for cupt to ugrade it, …

My humble opinion is that these either do not care for the state
of APT because it's not needed at this stage or they don't care
because they expect the user to handle his self-created problems…

Oh, and the special casing wouldn't be gone anyway, as it has another
lovely sideeffect: If you try to remove apt with APT it will scream loudly
that you try to remove an essential package, try to do it with dpkg:
No protection layer, do we need to implement one now because
users using dpkg doesn't seem to be able clean up there own mess
(at least, thats the current most prominent pro)?


Best regards

David Kalnischkies


Reply to: