Re: Pinning vs. conflicting [was: How to avoid stealth installation...]
On Jo, 03 iul 14, 00:24:44, Juliusz Chroboczek wrote: You have not yet explained why apt pinning is not enough. I'd appreciate an explanation too. I've inserted in my apt/preferences file the incantation given by Vitali F. (to whom thanks) at the very beginning of this thread, and it appears to have the requested effect. I've looked through the whole thread, and I can see the following reasons: - conflicting packages are honoured by dpkg, unlike pinning; Which doesn't bring any real additional benefits, unless you want to prevent yourself from ever doing 'dpkg -i systemd*.deb'. - a package can conflict with multiple packages, while you need multiple pinning entries; Pinning supports blobs and regexes, so it should be quite easy to pin a number of related packages with just one or few patterns. In case of systemd this is not even necessary, because the other related packages have Depends: systemd, and apt will refuse to install those as well. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Pinning vs. conflicting
Juliusz Chroboczek wrote: Emilio Pozuelo Monfort wrote: You have not yet explained why apt pinning is not enough. Simply because apt is not the only way to install packages. - conflicting packages are honoured by dpkg, unlike pinning; - a package can conflict with multiple packages, while you need multiple pinning entries; Right. Furthermore, pinning can be used by the local admin, without namespacing pin priorities or somesuch, so itâs not something packages should do. There is another benefit: conflicting packages allow all package managersâ resolvers to find nice dependency chains, they can be cleanly removed, and they show up in dpkg.log (and apt/term.log if apt is used to install them). bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lp35mr$3pp$1...@ger.gmane.org
Re: Pinning vs. conflicting
Hi,
Thorsten Glaser:
You have not yet explained why apt pinning is not enough.
Simply because apt is not the only way to install packages.
Don't synaptic and/or whatever honor these pins too?
Right. Furthermore, pinning can be used by the local admin,
without namespacing pin priorities or somesuch, so it’s not
something packages should do.
Since you don't need a package for creating a pin entry anyway, this is a
non-argument.
Why would you want to need a namespace for pin priorities?
-1 is sufficient to block installation and therefore doesn't conflict
with any other rules. What else would you need?
There is another benefit: conflicting packages allow all
package managers’ resolvers to find nice dependency chains,
… esp. since their dependency resolution algorithm ends up removing the
blocker package. As soon as there's the slightest hint of a conflict
*anywhere* in the dependency chain. Aptitude is notorious for this.
… unless you add a pin. In which case you can add a pin to prevent
systemd{,sysv} from installing anyway.
--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140703110025.gb23...@smurf.noris.de
Re: Pinning vs. conflicting
Matthias Urlichs wrote: Thorsten Glaser: You have not yet explained why apt pinning is not enough. Simply because apt is not the only way to install packages. Don't synaptic and/or whatever honor these pins too? I have no idea about synaptic, but there’s e.g. cupt (which works as apt replacement, but probably (didn’t check) handles its configs the same…) and dselect (which uses dpkg and thus is one level “below” apt, and cannot be reasonably expected to use apt’s configs). Also, dpkg itself does have a dependency resolver, which works only on the package relationships of course. Right. Furthermore, pinning can be used by the local admin, without namespacing pin priorities or somesuch, so it’s not something packages should do. Since you don't need a package for creating a pin entry anyway, this is a non-argument. Yes, but then you cannot just purge the entry easily. Why would you want to need a namespace for pin priorities? -1 is sufficient to block installation and therefore doesn't conflict with any other rules. What else would you need? I was talking about pinning in general here, not pinning for one specific case (preventing package installation). … esp. since their dependency resolution algorithm ends up removing the blocker package. As soon as there's the slightest hint of a conflict *anywhere* in the dependency chain. Aptitude is notorious for this. Aptitude may be… but apt at least honours “Important: yes” on the package, which I’ll add in my own next version and suggested Wookey to add as well, for a subsequent upload. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lp3fgb$36o$1...@ger.gmane.org
Re: Pinning vs. conflicting
You have not yet explained why apt pinning is not enough. Simply because apt is not the only way to install packages. Don't synaptic and/or whatever honor these pins too? I have no idea about synaptic, but there’s e.g. cupt (which works as apt replacement, but probably (didn’t check) handles its configs the same…) and dselect (which uses dpkg and thus is one level “below” apt, and cannot be reasonably expected to use apt’s configs). Isn't the proper solution to add blacklisting support to dpkg, then? (Which should not prevent getting the systemd-must-not-die-but-please-dont-install-it-on-my-system package into the archive.) -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioney6pj.wl@pps.univ-paris-diderot.fr
Re: Pinning vs. conflicting
At Thu, 03 Jul 2014 14:20:24 +0200, Juliusz Chroboczek wrote: You have not yet explained why apt pinning is not enough. Simply because apt is not the only way to install packages. Don't synaptic and/or whatever honor these pins too? I have no idea about synaptic, but there’s e.g. cupt (which works as apt replacement, but probably (didn’t check) handles its configs the same…) and dselect (which uses dpkg and thus is one level “below” apt, and cannot be reasonably expected to use apt’s configs). Isn't the proper solution to add blacklisting support to dpkg, then? No, the proper solution is pinning and that's already implemented. A quick search turns up a bug report about pinning in cupt, from which I conclude that cupt also implements it. Synaptic also implements it. And dselect is obsolete and doesn't even support things like multiarch (see #664893). It would also ask you to confirm installing extra packages if I remember correctly, but I haven't used dselect for a very long time. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oax636tt.wl%jer...@dekkers.ch
systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Folks, Le jeudi, 3 juillet 2014, 14.20:24 Juliusz Chroboczek a écrit : Isn't the proper solution to add blacklisting support to dpkg, then? The proper solution is to stop trying to hide ourselves from to the fact that some sort of systemd interfaces have been made unavoidable in modern desktop environments (fact which is rightfully reflected in our dependencies tree). Many of the interfaces of systemd are here to stay and will make their way through our stack (like it or not); fact is they already made it quite far in at least Gnome and KDE. As developers of Debian (which this list is about afterall), our proper solution is not to forbid systemd on our various systems while hoping that not too many things will end up depending on its interfaces and that our working setup for so long that I can't even remember will magically keep working while the underlying stack keeps evolving (with or without systemd btw). Given that the technical committee has made a decision which stayed unchallenged (so far), I've now come to think that this behavior (and its flaming counterpart) is actively hurting the project. The proper solution is to fix (or help fix) all use-cases that became broken with the arrival of systemd and/or make sure that the dependencies tree allows the systemd shim to be installed and working, as well as making sure this shim stays relevant and a working and transparent replacement to systemd itself. We are collectively developing an operating system, not only assembling a set of packages for our own benefit. Our priority is our users and they rightfully expect a rocking Jessie release, which will happen with systemd as default init system. Will we make this happen or will we just end up having gone through an endless bikeshedding discussion about a package that forbids the installation of the default init system!? Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Didier, Hello. The proper solution is to stop trying to hide ourselves from to the fact that some sort of systemd interfaces have been made unavoidable in modern desktop environments (fact which is rightfully reflected in our dependencies tree). Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? For some of us there will never be an awesome Debian release that at it's core contains systemd. It's core developers, Lennart Poettering and Kay Sievers, work for a company that has multi-billion dollar contracts with NSA. It is your choice to assume good faith on their part. It is our choice not to. Please respect our decision to stay away from systemd and still be Debian users. If possible, please, don't resist changes that make our lives easier. -- For shame deny that thou bear'st love to any, Who for thy self art so unprovident. Grant, if thou wilt, thou art beloved of many, But that thou none lov'st is most evident: For thou art so possessed with murderous hate, That 'gainst thy self thou stick'st not to conspire, Seeking that beauteous roof to ruinate Which to repair should be thy chief desire. O! change thy thought, that I may change my mind: Shall hate be fairer lodged than gentle love? Be, as thy presence is, gracious and kind, Or to thyself at least kind-hearted prove: Make thee another self for love of me, That beauty still may live in thine or thee. W. Shakespeare
Re: systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Hi, Alexander Pushkin: It's core developers *Its. I think we can do without (quite unfounded, IMHO) insinuations that systemd is somehow infected with an NSA-sponsored backdoor or two, thank you very much. Please respect our decision to stay away from systemd and still be Debian users. If possible, please, don't resist changes that make our lives easier. *Sigh*. The problem is not that anybody resists such changes. The problem is that some people bitch endlessly abut how evil systemd is _instead_of_ producing software (not just patches) to replace what systemd offers. For thou art so possessed with murderous hate, Three words do come to mind … which I'll not write down here, in order not to escalate this discussion. You may mail me your guesses privately. ;-) -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140703184059.ge23...@smurf.noris.de
Re: systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Hi, Matthias Urlichs matth...@urlichs.de writes: Please respect our decision to stay away from systemd and still be Debian users. If possible, please, don't resist changes that make our lives easier. *Sigh*. The problem is not that anybody resists such changes. I disagree. People *do* in fact resist changes that makes the live of other people considerable easier. Sorry to say so, but this is effectively what all this FUD and useless discussion about packages depending on systemd is about -- resisting a change, that makes the live of the maintainers and developers of said packages considerable easier. I find it deeply funny and ironic that this is actually used to defend the very same behaviour, that is critized. So, if possible, please, systemd haters, don't resist changes that make our lives easier. Best, Merovius -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnt610ws.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me
Pinning vs. conflicting [was: How to avoid stealth installation...]
You have not yet explained why apt pinning is not enough. I'd appreciate an explanation too. I've inserted in my apt/preferences file the incantation given by Vitali F. (to whom thanks) at the very beginning of this thread, and it appears to have the requested effect. I've looked through the whole thread, and I can see the following reasons: - conflicting packages are honoured by dpkg, unlike pinning; - a package can conflict with multiple packages, while you need multiple pinning entries; - there's a number of user-friendly frontends to apt, while pinning requires using a text editor (the horror!). Are there any other reasons to prefer conflicting dummy packages, which, with all due respect to Thorsten and Wookey, are something of a hack. Thanks to everyone who helped, -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ha2zqtzn.fsf...@ijon.pps.univ-paris-diderot.fr
Re: Pinning vs. conflicting
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr writes: You have not yet explained why apt pinning is not enough. I'd appreciate an explanation too. I've inserted in my apt/preferences file the incantation given by Vitali F. (to whom thanks) at the very beginning of this thread, and it appears to have the requested effect. I've looked through the whole thread, and I can see the following reasons: - conflicting packages are honoured by dpkg, unlike pinning; - a package can conflict with multiple packages, while you need multiple pinning entries; You have to drop one file (you may even call it the same name that you'd use for the conflicting package) into /etc/apt/preferences.d/. That file can pin as many packages as you want. - there's a number of user-friendly frontends to apt, while pinning requires using a text editor (the horror!). Anyone who knows about (let alone is interested in) a package conflicting with systemd is most certainly able to drop a file into a directory. Now someone will probably suggest to create a package that doesn't conflict with anything but instead installs /etc/apt/preferences.d/no-systemd.conf Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g3v1d9k@vostro.rath.org
