On Thu, Apr 28, 2011 at 04:55, Peter Samuelson <pe...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimxt_rwfh1ftkfrfwwkn4xgowp...@mail.gmail.com
