Re: [DNG] Advice on a package pinning
Thanks for your well thought reply and advice. I have already applied your suggestions on the pinning strategy. I knew already how to filter with aptitude, but I didn't know the reference, thank you for the information. Some days ago I updated my basement pc from Jessie to Beowulf and It was all messed up. I managed to recover it, so I guess, if something happens to the one I am asking about, I will (hopefully) be able to recover it too :) Cheers! Antonio On Wed, Mar 17, 2021 at 7:29 PM Florian Zieboll wrote: > On Wed, 17 Mar 2021 16:18:03 +0100 > "Antonio Trkdz.tab" wrote: > > > Thank you Florian for your good advice on pinning strategy. > > What I am really scared of is if having installed different gcc > > packages could screw up my system. > > Does your strategy take into account this, i.e. is your suggestion a > > way to take care of such situations? > > did you have any such problems deriving from 'aggressively' mixing up > > releases? > > > Hallo Antonio, > > I am not into mixing 'aggressively' and usually don't have more than a > handful of packages (plus dependencies) from at most three "alien" > repositories - and it's really long ago that I messed up a system in a > way that was irrecoverably (for me). > > That said: I suppose, that if you don't go beyond "testing", the > packages' dependencies won't change in a way that would endanger your > system by just updating - of course given that you took care during the > initial installation of the "non native" packages. > > But please take my words with a good pinch of salt; on this list there > are much more experienced sysadmins than I am, who might have the one or > other cent to add to these my two lentejas! (Not sure if silence has to > mean consent - it might be a mail filter towards /dev/null as well;-) > > NB, as it took me a while to figure out how to do it: With aptitude, you > can easily filter installed packages by archive name or origin (URL): > > $ aptitude search "?narrow(~i, ~A$archive)" > or > $ aptitude search "?narrow(~i, ~O$origin)" > > Of course, $archive and $origin need to be replaced or defined. Also, if > you don't know it already, I recommend to have a look at the aptitude > search term reference, it can be *VERY* useful: > https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html > > > libre Grüße, > Florian > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Advice on a package pinning
On Wed, 17 Mar 2021 16:18:03 +0100 "Antonio Trkdz.tab" wrote: > Thank you Florian for your good advice on pinning strategy. > What I am really scared of is if having installed different gcc > packages could screw up my system. > Does your strategy take into account this, i.e. is your suggestion a > way to take care of such situations? > did you have any such problems deriving from 'aggressively' mixing up > releases? Hallo Antonio, I am not into mixing 'aggressively' and usually don't have more than a handful of packages (plus dependencies) from at most three "alien" repositories - and it's really long ago that I messed up a system in a way that was irrecoverably (for me). That said: I suppose, that if you don't go beyond "testing", the packages' dependencies won't change in a way that would endanger your system by just updating - of course given that you took care during the initial installation of the "non native" packages. But please take my words with a good pinch of salt; on this list there are much more experienced sysadmins than I am, who might have the one or other cent to add to these my two lentejas! (Not sure if silence has to mean consent - it might be a mail filter towards /dev/null as well;-) NB, as it took me a while to figure out how to do it: With aptitude, you can easily filter installed packages by archive name or origin (URL): $ aptitude search "?narrow(~i, ~A$archive)" or $ aptitude search "?narrow(~i, ~O$origin)" Of course, $archive and $origin need to be replaced or defined. Also, if you don't know it already, I recommend to have a look at the aptitude search term reference, it can be *VERY* useful: https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Advice on a package pinning
Thank you Florian for your good advice on pinning strategy. What I am really scared of is if having installed different gcc packages could screw up my system. Does your strategy take into account this, i.e. is your suggestion a way to take care of such situations? did you have any such problems deriving from 'aggressively' mixing up releases? Thank you once more for your reply. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Advice on a package pinning
On Wed, 17 Mar 2021 12:49:56 +0100 Florian Zieboll via Dng wrote: > On Wed, 17 Mar 2021 12:00:19 +0100 > "Antonio Trkdz.tab via Dng" wrote: > > > Hello all, > > > > I could use some advice on a package pinning which I have set. > > I need a version of ripgrep (>11.0) only available in Ceres repos. > > Hence, I enabled the ceres repo in my sources.list file and I pinned > > all packages from this release with: > > > > Package: * > > Pin: release n=ceres > > Pin-Priority: -1 > > > > After I enabled the package and its dependencies with: > > > > Package: ripgrep libgcc-s1 gcc-10-base > > Pin: release n=ceres > > Pin-Priority: 660 > > > > With this I installed the intended version of ripgrep. However I am > > afraid that the dependencies could cause problems as gcc packages > > are involved, I have already seen a warning about outdated binaries > > during installation. What do you think? I am doing something wrong > > here? > > > > Additional repositories I don't want to take over my system, I manage > with pins 100 <= P < 500, in the order of priority. The following > example allows me to have e.g. some packages from backports and some > from chimaera on my beowulf system, without having to edit the pins > for every newly installed "custom" version and its dependencies. > Updates and dependencies get installed as usual and the packages from > backports will not be upgraded to chimaera: > > Package: * > Pin: release n=beowulf-backports > Pin-Priority: 150 > > Package: * > Pin: release n=chimaera > Pin-Priority: 140 > > libre Grüße, > Florian Or to say it differently: Like this I can just run $ apt install -t chimaera ripgrep and forget about it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Advice on a package pinning
On Wed, 17 Mar 2021 12:00:19 +0100 "Antonio Trkdz.tab via Dng" wrote: > Hello all, > > I could use some advice on a package pinning which I have set. > I need a version of ripgrep (>11.0) only available in Ceres repos. > Hence, I enabled the ceres repo in my sources.list file and I pinned > all packages from this release with: > > Package: * > Pin: release n=ceres > Pin-Priority: -1 > > After I enabled the package and its dependencies with: > > Package: ripgrep libgcc-s1 gcc-10-base > Pin: release n=ceres > Pin-Priority: 660 > > With this I installed the intended version of ripgrep. However I am > afraid that the dependencies could cause problems as gcc packages are > involved, I have already seen a warning about outdated binaries > during installation. What do you think? I am doing something wrong > here? Additional repositories I don't want to take over my system, I manage with pins 100 <= P < 500, in the order of priority. The following example allows me to have e.g. some packages from backports and some from chimaera on my beowulf system, without having to edit the pins for every newly installed "custom" version and its dependencies. Updates and dependencies get installed as usual and the packages from backports will not be upgraded to chimaera: Package: * Pin: release n=beowulf-backports Pin-Priority: 150 Package: * Pin: release n=chimaera Pin-Priority: 140 libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
