| View previous topic :: View next topic |
| Author |
Message |
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
 Posted: Tue Jan 02, 2018 7:55 pm Post subject: |
 |
|
| asturm wrote: | - B, installed, not in world, no rdeps, is not considered for rebuild and continues to insist on :1/1
Portage is not able to resolve the conflict. |
Good example, however i doubt (that's something to test indeed!) portage would react like that.
from manual, i read := Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package specifying the dependency will break unless there is available....
So C:1/2 is fine for A as long as A is rebuild because C:1 is rdep of A
But C:1/2 is also fine for B because C:1 is not rdep of B, no need to rebuild B, no conflict there.
If you upgrade to C:1/2 portage should rebuild A, and ignore B (and B would even not be broken, useless, but still working).
You could fall into conflict if someone is doing "emerge -1 B", but this is if user is doing that, if user is doing like user do "emerge system/world", B is not in them (of course that's why it is "useless") and portage will not care about it.
So, you are saying basically "it is critical to use --depclean because not doing so if you try to do something on a useless package, you may get a conflict"...
I'm still not seeing this as critical sanity maintenance sorry ; and if you balance vs "user may lost something using --depclean" (which is not limited to kernel sources, even it's really typical, forum has plenty examples of depclean removing libmpfr, binutils, gcc, nano...), i still think user will have an happier life not using depclean, even user may one day ask portage to rebuild a useless package and may get a conflict as result.
Keep also in mind, if "useless" package is out of the tree, it's even easier, because portage will even tell user the ebuild is missing (which should hint user to -c the package). |
|
| Back to top |
|
 |
asturm
Developer
Joined: 05 Apr 2007
Posts: 8972
|
| Posted: Tue Jan 02, 2018 8:19 pm Post subject: |
|
|
| krinn wrote: | So C:1/2 is fine for A as long as A is rebuild because C:1 is rdep of A
But C:1/2 is also fine for B because C:1 is not rdep of B, no need to rebuild B, no conflict there.
If you upgrade to C:1/2 portage should rebuild A, and ignore B (and B would even not be broken, useless, but still working). |
No, you got that wrong. rdep means reverse-dep as I told beforehand. := is only effective for runtime-deps, so that is implied because it does not make sense as a build-time dep. So both reverse-deps A and B would need a rebuild, but only A is in the depgraph.
| krinn wrote: | | Keep also in mind, if "useless" package is out of the tree, it's even easier, because portage will even tell user the ebuild is missing (which should hint user to -c the package). |
That's not how it works in practice. Where do they see it is missing? eclean shows you, but not enough users seem to know it or care about its output. People simply are not aware of how many orphans they have installed. You can't imagine how often I've had to hammer '--deplean' into people's minds because even one year after, they still got long obsolete Plasma-4 related packages installed, or kde-apps that have long been last-rited. Then a USE flag is dropped from libs, on which those old packages had depended on, and of course portage update is blocked. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 02, 2018 8:36 pm Post subject: |
|
|
| asturm wrote: | | So both reverse-deps A and B would need a rebuild, but only A is in the depgraph. |
- Either portage see B needs rebuild and you have a conflict (well, you have none in real, B could be rebuild)
- same case, but B cannot be rebuild because the ebuild is no more in the tree -> really, portage will tell you about this (there's a message for that, i've saw it more than once)
- Or like you say, portage won't put B in the depgraph, how could then portage emit any conflict as B is not in the graph?
(in this case, B will not be rebuild, will end broken by C update, and revdep-rebuild will catch B issue), or user trying to run B, anyway, B is broken, but i still fail to see the conflict.
| asturm wrote: | | Where do they see it is missing? |
Really just from portage, but it need to be in the graph, something a user could do trying some "emerge -pv B"
revdep-rebuild also report it
I'm less sure, but i think equery report it too (or it's portage reporting it thru equery)
I'm not using depclean, nor really i use eclean, so i'll trust you eclean report it too.
This make a lot of tools that will report it.
Last edited by krinn on Tue Jan 02, 2018 8:39 pm; edited 1 time in total |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8972
|
| Posted: Tue Jan 02, 2018 8:39 pm Post subject: |
|
|
| krinn wrote: | | (in this case, B will not be rebuild, will end broken by C update, and revdep-rebuild will catch B issue), or user trying to run B, anyway, B is broken, but i still fail to see the conflict. |
You've never seen a slot conflict caused by 'installed' packages vs. 'scheduled for merge'? B can not be broken is exactly what the subslots were invented for. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 02, 2018 8:42 pm Post subject: |
|
|
| asturm wrote: | | krinn wrote: | | (in this case, B will not be rebuild, will end broken by C update, and revdep-rebuild will catch B issue), or user trying to run B, anyway, B is broken, but i still fail to see the conflict. |
You've never seen a slot conflict caused by ::installed packages? |
Yes, plenty times, but never by a package that wasn't in the graph, and a useless package is never in the graph if you don't specially name it.
To my knowledge: Packages are only in graph when another package depends on it (build, reverse, or runtime), or when the package is in world (or system because it is in world) or when add by user (user gave the package name to emerge).
Because B is useless, it is not in system, not in world and not use by anyone : how could it end up in the graph if none specify it to emerge then? |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8972
|
| Posted: Tue Jan 02, 2018 9:37 pm Post subject: |
|
|
You're right, I was misunderstanding the way that portage is calculating subslot rebuilds. I've learned something today.  Needless to say, that the biggest issues actually come from polluted world files that --depclean can do nothing about. |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 497
|
| Posted: Wed Jan 03, 2018 3:34 am Post subject: |
|
|
| Genone wrote: | | yzg wrote: | | My question is simple: does it make sense for "emerge --depclean" to un-emerge the current kernel? |
This question is a lot more complex than it seems (I recall having this discussion many years ago already).
First you need to define exactly what "current kernel" refers to. "So the current kernel is the installed version of sys-kernel/gentoo-sources." is way too vague as you can have many versions of different kernel sources installed at the same time. Basically there are two (three) variants to define "current kernel source package" (just to be clear that we're talking about the sources, not the binary image): Either by following the /usr/src/linux symlink, or by locating the sources that were used to build the currently running kernel image (or alternatively the image that would be loaded on next boot). However none of these variants fit very well into the dependency scheme used by portage. Basically you'd have to create a virtual package "sys-kernel/current-sources" inside portage that contains a dynamic dependency on the "current kernel source package" as defined above. That wouldn't be a big deal, except that dynamic dependencies don't work well with the metadata variable caching of portage, so it'd require special casing in many places. And special cases are generally the primary cause of problems. |
@Genone. I understand the difficulty associated with the kernel because it is installed and maintained manually. But it is, like anything, we make up a definitions of what we mean by the current kernel. I think it is the /usr/src/linux symlink because the main reason for keeping the kernel sources is to re-compile after driver update or configuration change.
The other option is "emerge --depclean" will not handle the kernel cleaning at all. If portage delegates the build and installation of the kernel to the user (mad user according to @krinn ), then it should also delegate the cleaning to the user. It is partially doing this now. |
|
| Back to top |
|
|
fe00
n00b
Joined: 19 Dec 2016
Posts: 7
|
| Posted: Wed Jan 03, 2018 8:28 am Post subject: |
|
|
| krinn wrote: | | fe00 wrote: | | Quote: | Yet it breaks the system: i.e. just try to update "sys-fs/zfs-kmod" which needs the kernel sources.
| Quote: | | Breaking a package build is a completely different thing than breaking the system. |
|
No, in case of ZFS: you build + install your new kernel, remove the old one by sources, *and cannot* upgrade ZFS filesystem anymore. So the system is stuck in software upgrades. Thats a broken system to me. |
Sorry, again no, your current zfs version is not broken and still running.
All packages that depends on kernel source will fail when kernel sources are gone, it's not new, nvidia-drivers is typical example (as certainly more common case).
But it doesn't mean your nvidia drivers are broken, and your system is running fine.
I don't know any packages that use kernel sources as run dependency. |
Congratulations: You win. The system is rotten nevertheless: no more security updates, may-be error corrections in ZFS for the world - but not for me... & my personal favorite of gentoo is gone: seamless rolling-release managed system. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Jan 03, 2018 9:40 am Post subject: |
|
|
| yzg wrote: | | (mad user according to @krinn ) |
I'm not saying users are mad to run depclean in real, there's a sublety.
I'm saying, users run depclean like mad. The difference is that users are not mad to run depclean, it's not a bad tool, but like many tool, not well use, it could harm.
But as users are running depclean "like made", it mean they run it so many times, that their initial good approach to use --pretend with it, and to actively watch what depclean is about to do (it's something hard sometimes, when you see package names in the list and you have just no idea what they are for, because you don't yourself use them, but they were deps on something you were using) is change into, "bah, let's just depclean and it will do the job for me".
You even have users using depclean from cronjob and "update" script.
And new users are instruct by others to run depclean, but how many of these new users will in real read about depclean? How many of them will understand the concept of "what is a useless package for depclean" (even they will easy get the concept that a "useless" package will be removed).
That's the primary cause of complain from users on depclean, because kernel source is certainly the top "wrongly" (still for users that misconcept what is "useless" for depclean) removed.
But when I (yeah I, by helping people in forum and see what they have let depclean done) always see users put blame on depclean, gentoo-sources, devs, whatever, but never themselves : they have use a tool, a tool that is not a brain, a tool that use a dirty strict logic to tag something as "useless" and they didn't care to do anything to mark something they want keep as "if you think it's useless, i'm telling you, IT IS NOT".
And that's for "known package" for users.
When you see a package you have no idea what it is for, you should somehow a few check what it is for (some emerge -s pck or equery d pck) and try to figure out "if i remove this one, will everything will be ok?"
It is in real a pain to check them all, and users EVEN when they are using pretend or ask with depclean are seeing "hey, i'm about to remove dev-libs/mpfr, that's ok?" are just hitting the yes button.
There's ways to use properly depclean (told them already masking or add version in world) and way to protect from your own ignorance (you could quickpkg the list of packages depclean is showing and if something important was removed, you can easy recover it with the binary).
But you have another easier way to protect yourself from depclan, by just not running it at all : at the cost of "disk space" (it is still to prove if depclean do something better than just get back space, but until this is done, it just do that for me). |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Jan 03, 2018 9:58 am Post subject: |
|
|
| fe00 wrote: | | Congratulations: You win. The system is rotten nevertheless: no more security updates, may-be error corrections in ZFS for the world - but not for me... & my personal favorite of gentoo is gone: seamless rolling-release managed system. |
Oh please don't go, keep using gentoo  *crying*
zfs is certainly the best fs ever made
it's all fault of depclean that should be an IA
We will ssh to your box and do security updates for you.
Please don't, or at least, create a "i'm gone" thread please. |
|
| Back to top |
|
|
fe00
n00b
Joined: 19 Dec 2016
Posts: 7
|
| Posted: Wed Jan 03, 2018 3:05 pm Post subject: |
|
|
| krinn wrote: | | fe00 wrote: | | Congratulations: You win. The system is rotten nevertheless: no more security updates, may-be error corrections in ZFS for the world - but not for me... & my personal favorite of gentoo is gone: seamless rolling-release managed system. |
Oh please don't go, keep using gentoo *crying*
zfs is certainly the best fs ever made
it's all fault of depclean that should be an IA
We will ssh to your box and do security updates for you.
Please don't, or at least, create a "i'm gone" thread please. |
It is disturbing for me that the victim is blamed "that his behaviour provoked the attack itself..."!
The post in question has had nothing factual to do with the subject of the discussion, but is solely aimed at mocking me and putting me under pressure. It's disgusting and worth a real apology. However, this would require a deep understanding of the problem: krinn seems to be so convinced of his professional opinion that any means is right to enforce it. And no matter whether his opinion is correct or not: he should work with arguments, not fight people - that is unacceptable.
I may not be registered in this forum for a long time yet and fit wonderfully into the scheme in which people with many posts harshly want to represent their well-established opinion: from my point of view, such persons do enormous damage to the matter by bashing others and should be disciplined. |
|
| Back to top |
|
|
Marlo
Veteran
Joined: 26 Jul 2003
Posts: 1591
|
| Posted: Wed Jan 03, 2018 3:52 pm Post subject: |
|
|
| asturm wrote: | | ... Needless to say, that the biggest issues actually come from polluted world files... |
https://wiki.gentoo.org/wiki/World_set_%28Portage%29#Keep_it_clean
There is an incredible amount of information available. The difficulty for me is to find them. I would have to ask the right question first. The index of the wiki could be a bit more precise. Or even better, a sitemap button included.
Ma
Mod edit: Repaired URL. — JRG
_________________
------------------------------------------------------------------
http://radio.garden/ |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 497
|
| Posted: Mon Jan 08, 2018 9:20 am Post subject: |
|
|
This can partially solve the problem. The exclude will force "emerge --depclean" to ignore the kernel. Then, the user manage the kernel cleaning safely outside this command.
| Code: |
emerge -a --depclean --exclude=sys-kernel/gentoo-sources
|
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jan 08, 2018 11:42 am Post subject: |
|
|
| yzg wrote: | This can partially solve the problem. The exclude will force "emerge --depclean" to ignore the kernel. Then, the user manage the kernel cleaning safely outside this command.
| Code: |
emerge -a --depclean --exclude=sys-kernel/gentoo-sources
|
|
I agree it will 100% handle gentoo-sources case, but it doesn't mean depclean is 100% safe still:
You are using -a with depclean, which mean depclean will show list of packages it will remove, and if you say "y", they are just gone.
Which mean if mpfr is in the list per example, mpfr is gone (in case you're not aware, it's a gcc run dep, which mean gcc is broken).
That's the problem with depclean, because it "mostly" work on packages you have no idea of what they are, not because they are hidden or whatever, but because you weren't interest by them : you may love vlc (the media player), you may have install vlc because you know vlc and want it, but vlc has pull pckA and pck B, you don't know what are pckA and pckB ; and if depclean start to show "hey i'll clean vlc, pckA and pckB you will answer "yes").
You only know from that list what is the package "vlc" and indeed you agree vlc could be remove, but for pckA and pckB you have roll a dice and count on luck pckA and pckB weren't need.
The proper way to deal with this, is
- check what pckA and pckB are which is time consuming and may not help, if you check mpfr you'll get "library for multiple-precision floating-point computations with exact rounding" ; while it hint you on what is does, it doesn't really answer "really, i need this?"
- or emerge -pv depclean -> take the list of package and quickpkg them all. While depclean may get nasty and remove something important, you'll have an easy way to recover it.
And even in the case when a user see depclean "i'll remove gentoo-sources-X" and forget it is his kernel source, he would still have gentoo-sources-X as binary safely keep to recover.
You may say, but why we endup with depclean removing something important?
Because of the strict rule depclean use, you can have "racing" conditions, user doing something on his system that endup meeting conditions, a bug in ebuild... that let a package appears useless for depclean, and removed.
If you want one real case easy to understand, let's see why "nano" was hit by depclean.
nano was default editor in gentoo (first time i install it in 2004, nano was there), and so nano was in @system ; protect from depclean. Of course nobody have nano in @world, so its sole protection was given by its presence in @system.
But some users prefer vim, some other emacs... and while they were adding vim, emacs... in their @world to keep them safe, portage keep insisting "nano" must be there (if you remove nano, nano was in @system, and portage will readd it always).
So devs think: "we could create a virtual/editor-0 and default it to use nano, and emacs, vim... will also use that" ; this way, we add editor-0 to @system and protect the editor user use, but user have the choice of the editor to use now.
All good: if user add emacs, he could remove nano, and emacs will be protect by editor-0 that is protect itself because it is in @system.
But you see the problem? nano is install, but it has been install prior the change to using the virtual/editor-0, so "that" nano doesn't use yet virtual/editor-0.
Result to this: virtual/editor-0 is protect from depclean because it is in @system, but who protect nano now? depclean see: "nano: it is not in @world, it is not in @system, nobody use it and nobody need it (because editor-0 is not yet a reverse dep of nano)" -> clean!
And users were having nano depclean.
This to show, without really a bug, depclean was trying to remove nano. Of course nano isn't really a big issue, still you can see how many users were asking "why depclean want to remove nano", but sometimes, something more important than nano is depclean, you can see some recent thread about depclean that was trying to remove openrc.
So because of a race condition, a bug in some ebuild, a user doing something he shouldn't do, or whatever case that let depclean start to tag wrongly a package for cleaning, finally the fault is to put on user that badly use depclean. depclean just never "wrongly" tag a package for cleaning, it always use the same logic, and that logic is not random at all and never fail. Hence the "there's no bug in depclean" some users have hard time to accept.
For me, the only failure is to suggest users to use depclean like it is a critical tool to use, when not using it make people only losing space, or perhaps, suggest them to use depclean, but instead of "read the manual", maybe a more useful link that would teach them better how to use depclean more safely, or just fully the logic use by depclean.
The tool isn't bad, the tool is useful, but the tool is also dangerous, but emerge -c is dangerous too, rm is dangerous, --nodeps is dangerous too... but people have no issue using dangerous tools knowing they are, and properly using them. |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 497
|
| Posted: Thu Mar 29, 2018 4:41 am Post subject: |
|
|
Guys, I raised this point sometime ago. I think it is a useful feature to have but since there was no consensuses on incorporating it into the emerge command, I wrote this simple script:
| Code: |
#!/bin/bash
echo excluding current kernel $(echo sys-kernel/gentoo-sources:$(uname -r | sed 's/-gentoo//')) ...
# Do the emerge --depclean command
emerge -a --depclean --exclude $(echo sys-kernel/gentoo-sources:$(uname -r | sed 's/-gentoo//'))
# Find the kernel directories in /usr/src with versions not installed
kerns=$(comm -3 --nocheck-order <( ls -1d /usr/src/* | grep gentoo | sort -V ) <( equery -Cq l -F'/usr/src/linux-$version-gentoo-$revision' 'sys-kernel/gentoo-sources' | sed 's/gentoo-$/gentoo/' | sort -V ))
# Ask to remove them
for i in $kerns
do
echo
echo "$i is not installed - Do you want to remove it?"
echo "remove it (y/N)? "
read tmp
if [[ "$tmp" != "y" ]]
then
echo Nothing was done.
exit
fi
rm -rf $i
done
|
Please note:
- The script assumes that you are using gentoo-sources kernel.
I hope you find it useful. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21918
|
| Posted: Fri Mar 30, 2018 2:32 am Post subject: |
|
|
| yzg wrote: | | Code: | | echo excluding current kernel $(echo sys-kernel/gentoo-sources:$(uname -r | sed 's/-gentoo//')) ... |
|
Why are you using echo here? It is unnecessary. | yzg wrote: | | Code: | | emerge -a --depclean --exclude $(echo sys-kernel/gentoo-sources:$(uname -r | sed 's/-gentoo//')) |
|
Why recompute the result of uname instead of caching it? | yzg wrote: | | Code: | | kerns=$(comm -3 --nocheck-order <( ls -1d /usr/src/* | grep gentoo | sort -V ) <( equery -Cq l -F'/usr/src/linux-$version-gentoo-$revision' 'sys-kernel/gentoo-sources' | sed 's/gentoo-$/gentoo/' | sort -V )) |
|
Using ls in a script is almost always a mistake. Using grep when globs are already in use is odd. Why not use find /usr/src/ -maxdepth 1 -type d -name '*gentoo*' instead of ls | grep?On principle, I would be very worried about a bare variable passed to rm -rf. |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 497
|
| Posted: Fri Mar 30, 2018 3:10 am Post subject: |
|
|
Thank you Hu for the suggestions
| Quote: | | Why are you using echo here? It is unnecessary. |
I wanted to make sure the script is excluding the current kernel.
| Quote: | | Why recompute the result of uname instead of caching it? |
I was just lazy and writing something for my own use.
| Quote: | | On principle, I would be very worried about a bare variable passed to rm -rf. |
I agree with you. The script gave you the chance to confirm before the rm -rf so it should be safe. |
|
| Back to top |
|
|
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
| Posted: Thu Jun 28, 2018 5:56 pm Post subject: |
|
|
This topic has some very useful information and opinions. Whether --depclean is a good or bad idea, really depends on how it gets used. I see to many people using it without careful examination of the packages to be cleaned. I use it consistently to keep my system clean of old obsolete packages. I never run --depclean without first running: | Code: | | emerge -avuND --with-bdeps=y @world |
after which I run: | Code: | | emerge --pretend --depclean --exclude sys-kernel/* |
running that command you are greeted with: | Code: |
* Always study the list of packages to be cleaned for any obvious
* mistakes. Packages that are part of the world set will always
* be kept. They can be manually added to this set with
* `emerge --noreplace <atom>`. Packages that are listed in
* package.provided (see portage(5)) will be removed by
* depclean, even if they are part of the world set.
*
* As a safety measure, depclean will not remove any packages
* unless *all* required dependencies have been resolved. As a
* consequence of this, it often becomes necessary to run
* `emerge --update --newuse --deep @world` prior to depclean. |
I always verify the packages --depclean wants to remove, especially if I am unsure why a package was added to the list before I commit and while its very rare I may have to solve an issue before I commit to --depclaen. These commands are always followed up withThis method has never failed me when done in a proper manner.
Its not the only tool I use to keep my systems clean. However, I do use it daily/weekly and when used properly it dose its job fairly well ...except without the | Code: | | --exclude sys-kernel/* |
you can find yourself in a predicament if you remove your kernel-sources and for some reason need to modify the kernel and then discover the kernel version you are using is no longer in portage. This happened to me years back before I new about the --exclude option and I was forced to upgrade my kernel. I was very unhappy when faced with that prospect back then. |
|
| Back to top |
|
|
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
| Posted: Thu Jun 28, 2018 7:33 pm Post subject: |
|
|
The one single issue I have with portage is how it handles kernel-sources. Unless I am testing a newer kernel I search for stable if possible, otherwise unstable kernels that support the hardware I intend to run it on. I search for security issues and out of kernel driver support for hardware that requires it. Upgrading a kernel is like using --depclean. You don't just runthen randomly make changes or change defaults without knowing the what you are doing. Its also time consuming. My first system it took me an entire day to get a working kernel. Now it only takes me an hour or so, but, with 4 systems, I can still spend a good portion of a weekend doing it. So unless I want to test newer kernels I only update my kernels once a year, unless I discover a security or other issue that needs to be addressed. More often than not the sources for the running kernels on my systems are either no longer in portage or the stable kernels are older then the ones I am currently running. This requires a lot of extra time and work keeping track of package.masking, removing unused kernel-sources and the like. I have one system that has no less than 6 kernel-sources installed by portage. That takes up a considerable about of drive space. While I haven't had the time to check yet I bet only one of them is even in portage anymore.
| asturm wrote: | | Your use of kernel version is your own responsibility, especially since build and install is not done by portage. |
This is very true. Maybe portage should never install or remove a kernel-source unless it is specifically asked to do so by the user. Is that even an option that could be added to portage.
| asturm wrote: | | No, it works as expected. Removing the sources does not break your already built kernel image and modules at all. If it is cleaned up it simply means a newer stable version is available, just as with any other package. |
I think that depends on what one considers breakage. While I was still in the learning process I had a kernel-source removed by --depclean and then needed to rebuild that kernel with some additional options enabled and I was unable to do so because the sources no longer existed on my system or in portage. This made for a very bad day at the time.
When I was new to gentoo I used what was stable and recommended at the time, not so much today. While I run mostly stable systems (my server is 100% stable packages), I don't rush out to upgrade any kernel unless absolutely necessary or they have gotten too old. When an upgrade is necessary I pick the kernels carefully and always from the sys-kernel/gentoo-sources tree. Most of my systems are updated via ssh, all at the same time and I don't always catch a new kernel-source install. So, I don't care for the fact that portage installs the latest stable kernel-source when I most likely will never use it. |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10591
Location: Somewhere over Atlanta, Georgia
|
| Posted: Thu Jun 28, 2018 7:46 pm Post subject: |
|
|
| OldTango wrote: | Its not the only tool I use to keep my systems clean. However, I do use it daily/weekly and when used properly it dose its job fairly well ...except without the | Code: | | --exclude sys-kernel/* |
you can find yourself in a predicament if you remove your kernel-sources and for some reason need to modify the kernel and then discover the kernel version you are using is no longer in portage. This happened to me years back before I new about the --exclude option and I was forced to upgrade my kernel. I was very unhappy when faced with that prospect back then. |
It's an easy problem to avoid: just add your specific kernel version to @selected and it will be protected from --depclean, just like every other member of that set. It's as easy as | Code: | | emerge --select --noreplace =sys-kernel/gentoo-sources-4.9.72 |
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
| Posted: Thu Jun 28, 2018 7:50 pm Post subject: |
|
|
The learning never stops does it? After reading through this topic and considering all the options it dawned on me that I should simply be able to run: | Code: | | emerge -avuND --with-bdeps=y --exclude sys-kernel/* @world |
Which should prevent portage form ever installing additional sources. Correct? |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10591
Location: Somewhere over Atlanta, Georgia
|
| Posted: Thu Jun 28, 2018 8:03 pm Post subject: |
|
|
Yes but you can make it so that you don't install new versions even without that option. Just make sure that no unslotted version of the kernel source is in the @selected set. For instance, here are the kernel source versions in my selected set: | Code: | ~ # grep gentoo-sources /var/lib/portage/world
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:3.18.25-r1
sys-kernel/gentoo-sources:4.9.72 |
That means that I have two specifically selected versions plus I also get the latest. If I didn't want to get the latest, I'd just remove that first line, typically with an editor. You can do it with emerge, too, though: | Code: | ~ # emerge --deselect gentoo-sources
>>> Removing sys-kernel/gentoo-sources from "world" favorites file...
>>> Removing sys-kernel/gentoo-sources:3.18.25-r1 from "world" favorites file...
>>> Removing sys-kernel/gentoo-sources:4.9.72 from "world" favorites file... |
Unfortunately that deselects everything, so: | Code: | secmt-service01 ~ # emerge --select --noreplace sys-kernel/gentoo-sources:3.18.25-r1 sys-kernel/gentoo-sources:4.9.72
These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 KiB
>>> Recording sys-kernel/gentoo-sources:3.18.25-r1 in "world" favorites file...
>>> Recording sys-kernel/gentoo-sources:4.9.72 in "world" favorites file... |
Note that --select is the default (if you don't specify --oneshot) so, although you can specify it, it's redundant. I just include it for conceptional symmetry.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
OldTango
l33t
Joined: 21 Feb 2004
Posts: 718
|
| Posted: Thu Jun 28, 2018 8:16 pm Post subject: |
|
|
@John R. Graham <--- Thank You
Very useful information |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
