Since sys-apps/portage-2.1.3.18 `emerge --depclean` wants to unmerge old kernel sources which is not really a good idea. This behaviour makes, btw., the slotted emerge of the kernel sources senseless and I think there are good reasons why every new version of the kernel sources is installed slotted for years. I'm just using gentoo-sources-2.6.23. Today an `emerge -uDN world` installed gentoo-sources-2.6.23-r1. Then `emerge --depclean` wanted to uninstall gentoo-sources-2.6.23 which I'm still using and which I still need. I can't or don't want to compile a complete kernel immediately after an `emerge -uDN world` but I want to uninstall every unnecessary dependency immediately after an `emerge -uDN world`. Even if I need to reconfigure the kernel I'm just using I can't always compile a complete kernel for time reasons. So I sometimes still need the older versions of a kernel source. sys-kernel/gentoo-sources is, btw., in my WORLD file. Actually `emerge --depclean` doesn't have to touch a package which is listed in the WORLD file anyway even if there are many slotted versions installed. And it can't be that one has to add every single kernel version to the WORLD file. For any other package this is also not necessary. So this behaviour of `emerge --depclean` has to be undone. `emerge --depclean` must not uninstall kernel sources and other packages listed in the WORLD file. And, btw., if `emerge -pv` is run before running `emerge` then everyone should see the "S" in the output and therefore knows that this package is installed slotted and the old versions of this package therefore aren't uninstalled automatically. So it's up to everyone him-/herself if he/she wants to waste too much disk space for old unneeded kernel sources.
If you don't want to remove redundant slots, then add them to world file. And no, this is not portage-2.1.3.18 specific, and not kernel-specific either. On a side note, unmerging currently used kernel is completely harmless, the only thing that gets unmerged are the sources.
Jakub, please, don't close this bug as invalid again because this is NOT invalid. The function of `emerge --depclean` is to remove unnecessary dependencies which are installed automatically by emerge because they are needed by another package and now are not needed by these packages anymore. Packages I've installed manually so that they are listed in the WORLD file MUST NOT be uninstalled by `emerge --depclean` even if they are slotted and there is more than one slot installed! And this is what makes the new `emerge --depclean` with the kernel sources. This is fact and this behaviour has to be removed from portage! And it was and still is definitely not the sense of the WORLD file to add every single version (slot) of a package into the WORLD file but only the package name and this is how it should work in future. In fact I had to put every single kernel version into the WORLD file or had to edit the WORLD file manually after every single kernel update, which is, btw., an impertinence. If a package I installed manually and/or put in the WORLD file has more than one slot then I AND ONLY I decide which and how many versions of this package are installed on my system because it can have - and regarding the kernels has - serious reasons for having more than one version of this package installed. Regarding your "harmless" because there are only the kernel sources and not the kernel itself, please, re-read my original comment and try to understand it. Read especially the thing about the time and compiling a complete new kernel. So this is a valid and serious bug which MUST be fixed. Additionally see this forums thread: http://forums.gentoo.org/viewtopic.php?p=4464101 You will see that I'm not the only one whom makes this behaviour serious troubles.
Please read the postinstall messages when installing portage. This behaviour is by design and exactly the same for ANY slotted package. If you don't want portage to get rid of redundant slots, add those slots to world, as you need to do with any other slotted package. NOTABUG.
Then there is a bug in the design and this design must be undone. So I'll keep reopening this bug. This behaviour is definitely impertinent and unusable. So this is still a serious bug. This is the old and only useful behaviour: IF I add a single version or slot to the WORLD file THEN `emerge --depclean` can of course uninstall every other older version of this package. But IF I add only a package name - WITHOUT a special version or slot - THEN `emerge --depclean` MUST NOT remove ANY version of this package. It's not and can't be that I mustn't add only a single package name but must add every single version or slot of a package to the WORLD file to avoid `emerge --depclean` from removing (old) versions of this package. This behaviour would be impertinent and not usable as I said before. Then I had to edit the WORLD file manually every time I run `emerge -uDN world` or even `emerge --sync`. This is definitely NOT usable and administratable.
Please stop. The whole purpose of --depclean it to get rid of unneeded stuff. Where unneeded == stuff that nothing depends on; not stuff that you dislike to be removed. The behaviour is documented, useful and if you dislike it, you have a documented way to avoid it.
(In reply to comment #5) > Please stop. The whole purpose of --depclean it to get rid of unneeded stuff. > Where unneeded == stuff that nothing depends on; not stuff that you dislike to > be removed. Now you've understood it. Unneeded is only what is needed by other packages as a dependency and not needed anymore by newer versions of these packages. Everything which I installed manually and therefore is listed in the WORLD file is not unneeded but NEEDED because I decided that this is needed on MY system. I don't like to repeat myself. If I add a package name without a version or slot number then I need EVERY version or slot of this package. If I add a package name with a version or slot then I only need - or want - this version or slot. So e.g. sys-kernel/gentoo-sources means I need/want every version of gentoo-sources while sys-kernel/gentoo-sources-2.6.23-r1 means I need/want only version 2.6.23-r1 of gentoo-sources. It is absolutely not administratable to add every single package version to the WORLD file if I need/want to keep every version of a package. In case of doubt I and not portage or a Gentoo developer decides what is needed on my system. And I again repeat myself `emerge --depclean` MUST NOT touch any package in my WORLD file because with this WORLD file I tell portage which package I need. The reason why I need more than one or every version of a package doesn't matter, btw. And, Jakub, this is a bad habit of you anyway to close such bug reports without giving the possibility to discus it with the responsible developers only because you think that everything which is changed by another developer is good and the best. Especially in this case this is not true. Also Gentoo developers can make mistakes and can miss some things in their decisions which is the case here. So, please, keep this bug report open until this behaviour of `emerge --depclean` is fixed and put back to the old behaviour.
If you want to discuss things, we have mailing lists for that. Bugzilla is for bugs and is not a discussion forum. > And I again repeat myself `emerge --depclean` MUST NOT touch any package in my > WORLD file because with this WORLD file I tell portage which package I need. Yeah, but you *didn't* tell portage you want those packages. Specifying a package there without slot doesn't mean you need every single slot out there, it means you want the latest one (exactly like emerge cat/foo won't install every slot out there, but only the highest visible version). If you do, then stick it to world. What's so horribly unclear about this? And, who's forcing you to use depclean for that matter if you want redundant cruft left on your system?
(In reply to comment #7) > If you want to discuss things, we have mailing lists for that. Bugzilla is for > bugs and is not a discussion forum. I know. But this IS a bug, either in the software or in the design. > > And I again repeat myself `emerge --depclean` MUST NOT touch any package in my > > WORLD file because with this WORLD file I tell portage which package I need. > > Yeah, but you *didn't* tell portage you want those packages. I DID tell portage I want those packages because I resp. portage itself added those packages (e.g. "sys-kernel/gentoo-sources") without giving a special slot to the WORLD file. > Specifying a > package there without slot doesn't mean you need every single slot out there, > it means you want the latest one (exactly like emerge cat/foo won't install > every slot out there, but only the highest visible version). No. It means - at least it meant or should mean - I need every single slot out there. If I need only a single slot or a single version then I can add the slot or version number to the package name. Otherwise `emerge <package name>` must not only add the package name but also every slot or version available and this must be updated automatically after every `emerge world`. > If you do, then > stick it to world. It was and still should only be necessary to stick a version or slot number to the WORLD file only if one want or need one single version or slot. > What's so horribly unclear about this? And, who's forcing you to use depclean > for that matter if you want redundant cruft left on your system? If you read my first comment then you would know that I don't want dependencies which I haven't installed manually and which are not needed by any other packages anymore. And for this I need `emerge --depclean`. But everything I installed manually is not redundant. It's only redundant if I decide that it is redundant. And these packages I can remove by myself. This is not the job of `emerge --depclean`. I expect `emerge --depclean` only to uninstall packages which are installed as a dependency of other packages and are not needed anymore by newer versions of the other packages. Especially with the kernel sources there are many reasons why this is bad to have them removed automatically by `emerge --depclean`. Maybe there could another different option implemented in emerge which can clear the packages listed in the WORLD file like e.g. `emerge --worldclean` which removes or in conjuction with -pv lists outdated slotted packages listed in the WORLD file. This could actually be a good option. But --depclean should - I repeat myself, I know - only remove unneeded dependencies. --worldclean could remove outdated slotted packages listed in the WORLD file. The thing with the kernel sources could then be done by `emerge --worldclean` but not by `emerge --depclean`.
(In reply to comment #8) > > Specifying a > > package there without slot doesn't mean you need every single slot out there, > > it means you want the latest one (exactly like emerge cat/foo won't install > > every slot out there, but only the highest visible version). > > No. It means - at least it meant or should mean - I need every single slot out > there. OK, so you are requesting that emerge sys-libs/db should emerge sys-libs/db:{1,3,4.2,4.3,4.5,4.6}? Or, you are not? Well, in that case what you are requesting is clearly inconsistent behaviour that makes no sense.
(In reply to comment #8) > Maybe there could another different option implemented in emerge which can > clear the packages listed in the WORLD file like e.g. `emerge --worldclean` > which removes or in conjuction with -pv lists outdated slotted packages listed > in the WORLD file. That sounds something like the --prune option which is already available. As for the --depclean behavior, you should simply run something like `emerge --noreplace =gentoo-sources-2.6.23` to add the slot that you want to keep to the world file. That's what the --depclean warning message tells you to do. In the future, we might add a way to toggle greedy SLOT behavior on package sets like world. I think the current --depclean behavior is fine though, considering that the world file supports SLOT atoms now.
Of course not. I mixed up the words "version" and "slot" a bit in my other comments. It's because I noticed this "new" behaviour of `emerge --depclean` with the gentoo-sources and in case of the kernel sources every kernel "version" has its own "slot". I of course want only the latest version of each slot and in case of the packages listed in the world file I want the latest version of every slot which was installed as long as I don't uninstall a slot by myself. If I e.g. install gimp by `emerge gimp` so that gimp is also added to the world file then I of course want only the latest version and not every version of gimp. So `emerge -uDN world` should of course update gimp and remove the old version as usual. But as soon as gimp is slotted then I of course want `emerge -uDN world` to install the newest version in the new slot. But then I don't want `emerge --depclean` to have the old version (the old slot) to be uninstalled automatically. Or to make a long story short I want or need the old behaviour of portage / emerge --depclean. To find and remove old or redundant slots of packages listed in the world file there could be a new parameter like --worldclean implemented in emerge as I suggested before. So if there were two slots of gimp installed and I only want the latest slot of gimp installed then I could run `emerge -pv --worldclean` which tells me that there are two slots of gimp installed and that it would uninstall every slot except for the latest. This could in fact help a lot. But this shouldn't or mustn't be done by `emerge --depclean` because there could be big changes in the new and slotted version of gimp so that I still need the old version of gimp. I know that gimp is not slotted but it's just a fictive example. Another real and much more problematic example is gcc. I haven't updated gcc to 4.2.2 on my system yet. But I think that the same problem would occur if I did it. So if I updated gcc then gcc-4.2.2 would be installed into another slot because of bigger ABI changes. Until I reemerged the whole system by `emerge -e system` and/or `emerge -e world` I still need gcc-4.1.5. If I ran `emerge --depclean` to remove unneeded dependencies gcc-4.1.5 would now also be removed which would break my system. And, yes, it can happen that I install gcc-4.2.2 and have to wait a while until I can reemerge the whole system. And it can happen that in the meantime I need to run `emerge -uDN world` and remove unneeded dependecies by `emerge --depclean` because `emerge -e system` and `emerge -e world` for me take about a week and I can't always do without my computer for a week. With the actual new behaviour of `emerge --depclean` I had three options. Either break my system by running `emerge --depclean`, being unable to work with my computer for about a week as soon as I updated to gcc-4.2.2 or waste (a lot of) diskspace and probably (not necessarily) make my system unstable by letting unneeded dependencies installed until I have time to leave my computer alone for a week. Neither is really good. With the old and used behaviour of `emerge --depclean` and a new parameter `--worldclean` I wouldn't have this problem.
> (In reply to comment #10) > That sounds something like the --prune option which is already available. Maybe. I haven't used --prune, yet. But if this already exists, why is this functionality needed and implemented in --depclean? > As for the --depclean behavior, you should simply run something like `emerge > --noreplace =gentoo-sources-2.6.23` to add the slot that you want to keep to > the world file. That's what the --depclean warning message tells you to do. Then I had to run `emerge --noreplace =gentoo-sources-<old version>` after every `emerge --sync` and/or `emerge -uDN world` and this not only for gentoo-sources but also for other packages. This is pretty equal to editing the world file manually and adding every single slot of a package to the world file. And this can't be the sense and is at least pretty unusable and not really maintainable. At least it makes much more work and makes it much more complicated to administrate a system than the old behaviour of --depclean. Even if this new behaviour may be easier to implement for the developers it makes it much harder for the users. This unfortunately is a rule in programming. Making software easier for the users means it is harder to write a program. Easier programming means it's less user-friendly. In case of doubt software should be more user-friendly and harder to program. > In the future, we might add a way to toggle greedy SLOT behavior on package > sets like world. I think the current --depclean behavior is fine though, > considering that the world file supports SLOT atoms now. I don't say anything against slot atoms in the world file but the slot atoms should only be optional. So if I add "media-gfx/gimp" to the world file then --depclean should leave every slot of gimp untouched as it did in the older versions. And if I only want gimp-2.4 (I know gimp is not slotted) to be installed but no other slots then I could add "media-gfx/gimp:2.4" to the world file and --depclean could remove every other installed gimp slot. Why is it such a problem to implement this? I mean it was already implemented but removed. Everyone who updates a slotted package sees in `emerge -pv` that it is slotted and can decide by himself if he wants to keep the old slots and can remove them manually or can run `emerge --prune` if this does what I meant --worldclean for. Why do the portage developer want to oblige the user which world packages to install or remove? Why must it be so complicated by obliging the users to alway edit the world file manually? This has nothing to do with user-friendliness. Why is it such a problem to let portage understand that e.g. "media-gfx/gimp" without a slot means that media-gfx/gimp shall be completely untouched by --depclan? This worked perfectly in the past. Why must a perfect working function be changed and complicated?
(In reply to comment #10) > In the future, we might add a way to toggle greedy SLOT behavior on package > sets like world. I think the current --depclean behavior is fine though, > considering that the world file supports SLOT atoms now. Well, should be farily easy to add a config option to WorldSet to include all installed slots if that is what you mean (pseudocode): if "include_installed_slots" in options: for a in atoms.copy(): r = varbdapi.match(a) if len(r) > 1: for cpv in r: atoms.append(catname(cpv)+":"+slot(cpv))
(In reply to comment #12) > Maybe. I haven't used --prune, yet. But if this already exists, why is this > functionality needed and implemented in --depclean? One difference is that --prune always leaves at least 1 SLOT installed, while --depclean can potentially remove all SLOTs. Another is that --prune always keeps the highest version, while --depclean removes any versions that are not required as dependencies of other packages. Both behaviors can be useful and while they have some things in common they also have important differences. > Then I had to run `emerge --noreplace =gentoo-sources-<old version>` after > every `emerge --sync` and/or `emerge -uDN world` and this not only for > gentoo-sources but also for other packages. This is pretty equal to editing the > world file manually and adding every single slot of a package to the world > file. And this can't be the sense and is at least pretty unusable and not > really maintainable. At least it makes much more work and makes it much more > complicated to administrate a system than the old behaviour of --depclean. Why do you need to keep so many obsolete SLOTs installed? In most cases, people only need the highest version or the versions that are required by dependencies. For the few cases where you need to keep additional SLOTs, it's not much work to add them to the world file. > Why is it such a problem to implement this? I mean it was already implemented > but removed. It's not much of a problem. I just think that the old behavior is as useful as you perceive it to be. I think the new behavior will be better for most people since obsolete SLOTs just bloat the system in most cases. > Why is it such a problem to let portage understand that e.g. "media-gfx/gimp" > without a slot means that media-gfx/gimp shall be completely untouched by > --depclan? That makes it more difficult for people to remove unwanted SLOTs. For example, see this email: http://archives.gentoo.org/gentoo-user/msg_117465.xml > This worked perfectly in the past. Why must a perfect working function be > changed and complicated? I really believe that the new behavior is better and I think that you are overestimating the burden that it creates.
(In reply to comment #14) > One difference is that --prune always leaves at least 1 SLOT installed, while > --depclean can potentially remove all SLOTs. Another is that --prune always > keeps the highest version, while --depclean removes any versions that are not > required as dependencies of other packages. Both behaviors can be useful and > while they have some things in common they also have important differences. Well, the only problem is the definition of "required as dependencies". I think we agree in this point that every package which is automatically installed as a dependency of another package and isn't used anymore if the other package is uninstalled or a new version of this package doesn't need this dependency anylonger. The problem are the packages in the world file. > Why do you need to keep so many obsolete SLOTs installed? In most cases, people > only need the highest version or the versions that are required by > dependencies. For the few cases where you need to keep additional SLOTs, it's > not much work to add them to the world file. I don't need so many obsolete SLOTs. I guess there are not much packages in my WORLD file which are slotted. The problem occurs mainly with the gentoo-sources. As long as I'm using one kernel version I need the sources - of course not for running the kernel but if I need to change the kernel config which happens from time to time. I don't always have time to compile a kernel immediately after the gentoo-sources are updated or if I need to make a small change in the kernel options. Of course I could always run `emerge --noreplace gentoo-sources-<version>`. But it's more work. And I usually don't want to maintain the world file. I usually want to install a package by `emerge` and keep it until I uninstall it manually by `emerge -C`. For this purpose is the world file in my eyes. And when e.g. gentoo-sources is updated then I know that this is installed slotted. So without this new behaviour I could keep the old kernel version until I compiled the newest kernel version and then just run `emerge -C gentoo-sources-<oldversion>` and everything is fine and I don't need to care about the world file and which SLOT is in the world file etc. It's just much easier. Afterwards I remember that I noticed this --depclean behaviour with phpmyadmin. There I found out that there were many slotted versions installed which I didn't really needed. But this is because I always forgot to unmerge the old versions after the updates. So it was not completely bad that there is a function which can remove those old SLOTs in the world file. But I don't like to have this done by --depclean for the reasons with the kernel and the gcc. For this purpose I'd like to see this function in a second parameter like --worldclean or maybe --prune. Then I can easily decide what I want to clean out. I think this is much easier to handle for the user and both features were implemented. I see a big difference in dependencies which are not used anymore and old SLOTs in the world file. I think the world file is just too sensible and therefore the user should have more control over it. And I think it's much easier to run `emerge --depclean` after an `emerge world` and to run `emerge --worldfile` (I call it --worldfile just to make clear what I mean) only from time to time to check my system for unneeded and outdated SLOTs of packages I installed manually. With this implementation first I don't need to care about the world file and second I don't need to edit the world file (run `emerge --noreplace`) after every `emerge --sync` or `emerge world` but would be able to clean out my world dependencies from time to time when I have time and when I want to do it. And I have to run even more commands if I see that `emerge --depclean` wants to remove a package from the world file because then I have not only to run `emerge --noreplace` but `emerge -p --depclean` for a second time to check it. Ok typing one command doesn't take so much time but it takes time and is more work which is in my opinion not necessary. And maintaining the world file in this way takes also more time and is especially for new Linux/Gentoo users more complicated. > It's not much of a problem. I just think that the old behavior is as useful as > you perceive it to be. I think the new behavior will be better for most people > since obsolete SLOTs just bloat the system in most cases. You're principally right. And for this reason I'd like this functionality but I'd like it to be implemented in a different parameter to have more control over the system and to be more flexible. > That makes it more difficult for people to remove unwanted SLOTs. For example, > see this email: > > http://archives.gentoo.org/gentoo-user/msg_117465.xml Not really. If you would make the SLOTs in the world file optional and let portage/emerge --depclean interpret the world file entries as I suggested then Daniel could add "cross-avr/gcc" (I can't find a section cross-avr in the portage tree, btw.) then `emerge --depclean` wouldn't uninstall every version. If he wants to keed the latest and one older version which is stable and what he knows then he could not add "cross-avr/gcc" but "cross-avr/gcc:3.4" or "cross-avr/gcc-3.4.4-r1" and "cross-avr/gcc:4.2" or "cross-avr/gcc-4.2.2" to the world file and `emerge --depclean` knows that it has to keep only these two version but can remove any other version. Maybe - I don't know if this is possible to implement - instead of "gcc-4.2.2" one could add "cross-avr/gcc-latest" then `emerge --depclean` would know that it shall keep gcc-3.4.4-r1 and the latest version which version this may be. Would be another option. And even better, also in this case, `emerge --depclean` wouldn't touch the world file. And `emerge --worldfile` would care about the world file and would check which SLOTs of a package are added to the world file in the way I mentioned above. I'll think about this again tomorrow. Maybe I can think of another better method. > I really believe that the new behavior is better and I think that you are > overestimating the burden that it creates. I don't think that I'm overestimating it but I like user-friendliness, I like to have a bit more control over my system and I don't like too automated processes. Maybe you could think about my suggestion with the second parameter --worldclean or --prune if this really does what I mean with --worldclean. I don't know if this is the ulitmate implementation but I think it's at least more secure and more flexible. Maybe one could think of implementations which are even better. As I said before I'll think about it again. If you look at http://forums.gentoo.org/viewtopic.php?p=4464782 then you will see that there are at least two other people who agree with me.
I disagree with Heiko Baums assertion that every slot of a package in world should be kept. I have no need for old, never used, kernel sources. *But* currently installed kernels are special, and the currently running kernel is *extra* special (as is the one pointed to by /usr/src/linux). It is *not* ok to unmerge the current kernel without any warning at all. There are packages that will not install without access to the source of the current kernel. For example x11-drivers/ati-drivers. Also, kernels have a long installed life (they are a pain to configure), and a short life in portage. So the slot you need is likely to be no longer in the portage tree, making repairs difficult
(In reply to comment #16) > It is *not* ok to unmerge the current kernel without any warning at all. Obviously we don't want to hardcode a bunch of package-specific warnings into portage. One way that you could configure portage to warn would be to add something like this to /etc/portage/bashrc: if [ "${EBUILD_PHASE}" == "prerm" ] && \ [ "${PN}" == "gentoo-sources" ] && \ [ "$(uname -r)" == "${PV}" ]; then echo "Do you really want to unmerge" echo "the currently running kernel?" echo "Press 'Enter' to continue or " echo "Ctrl C to cancel." read fi
Can someone WONTFIX this bug? Because it's getting completely nonsensical. Unmerging kernel sources breaks *nothing*. The kernel stays there, the modules stay there. If you have enough disk space to waste, then stick the slots you can't live without to world or use a bashrc hook to do it for you after every emerge.
(In reply to comment #18) > Can someone WONTFIX this bug? Because it's getting completely nonsensical. Jakub, this bug is NOT getting nonsensical. I just hadn't had time enough to answer again. And this new --depclean behaviour mixes definitively two completely different functions which DO have to be implemented in two functions. > Unmerging kernel sources breaks *nothing*. The kernel stays there, the modules > stay there. Unmerging kernel sources DO break many things. Read comment #16 by Ralph Hartley. Even if it doesn't break the running system it makes administrating and recompiling the kernels MUCH harder and MUCH more complicated as I and Ralph Hartley described it. > If you have enough disk space to waste, then stick the slots you can't live > without to world or use a bashrc hook to do it for you after every emerge. This has definitely nothing to do with wasting disk space. To help with cleaning up disk space it could easily - VERY easily - a second function be implemented which removes older and possibly unused WORLD packages but this MUST NOT be done by --depclean. As the name of this parameter says this is used for just removing dependencies which are not used any longer. WORLD packages are NOT dependencies. I agree with Ralph Hartley when he says that old versions of WORLD packages are usually not needed anymore except of old kernel sources. But I disagree that these old WORLD packages shall be cleaned by --depclean. Again the question to the portage developers: Why isn't it impossible to remove this new behaviour from depclean and put this new function into a second parameter like --worldclean? I don't see any reasons why this shouldn't be possible. Once again... I'm not against this feature in general but I'm against this new feature being mixed up with another completely different feature.
Comment #16 is just irrelevant. --depclean doesn't exist to work around binary package suckage (or any other borkage related to kernel upgrade), it's there for people to get rid of unneeded stuff... And noone's forcing you to use it for that matter if you have it that much. Special-casing stuff like kernel sources (which you can download at any time from whatever kernel mirror) doesn't make any sense.
(In reply to comment #17) > Obviously we don't want to hardcode a bunch of package-specific warnings into > portage. One way that you could configure portage to warn would be to add > something like this to /etc/portage/bashrc: > > if [ "${EBUILD_PHASE}" == "prerm" ] && \ > [ "${PN}" == "gentoo-sources" ] && \ > [ "$(uname -r)" == "${PV}" ]; then > echo "Do you really want to unmerge" > echo "the currently running kernel?" > echo "Press 'Enter' to continue or " > echo "Ctrl C to cancel." > read > fi This would change anything because you already get this warning if you run `emerge -p --depclean` first. The problem with this solution is that you still can't remove old and really unnecessary dependecies without compiling the new kernel and every third party kernel modules and packages which need the kernel sources for compiling first. And compiling a new kernel completely takes much more time than recompiling an already compiled kernel. And again if you keep this new --depclean behaviour in portage or at least in --depclean you could remove the SLOT feature from portage completely because this new behaviour deactivates the SLOTs and ingnores the sense of the SLOTs. I asked the question why this feature can't be just implemented into a second parameter already in my last comment. This wouldn't do any harm for the portage developers and would make thing MUCH easier for the users. And everyone who don't want to keep older SLOTs of WORLD packages like Ralph Hartley could easily run e.g. `emerge --depclean --worldclean` instead of just `emerge --depclean`. I don't see any problem in such an implementation. But I see a problem in the current implementation.
(In reply to comment #21) As noted above, *nothing* is stopping you from doing 'echo ${CATEGORY}/${PF} >> /var/lib/portage/world' in /etc/portage/bashrc as postinst hook. I really don't see what are you arguing here. Telling people that they need every single kernel source they've ever installed just because you can't deal with this doesn't make sense.
(In reply to comment #20) > Comment #16 is just irrelevant. It's not completely irrelevant. Only a few details possibly. > --depclean doesn't exist to work around binary > package suckage (or any other borkage related to kernel upgrade), This wasn't said by anyone. But he is right when he says that many kernel related packages like ati-drivers or nvidia-drivers, klibc, svgalib, iptables etc. are using the actually used kernel. > it's there > for people to get rid of unneeded stuff... No! It's there for get rid of unneeded old dependencies. That's why this parameter is called "depclean" and not "packageclean", "worldclean", "systemclean", "portageclean" or whatever. > And noone's forcing you to use it > for that matter if you have it that much. I AM forced to use depclean because I can't get rid of unneeded old dependencies without this function. And leaving these unneeded old dependencies waste MUCH more diskspace as one or two older, possibly unneeded SLOTs of one or two world packages like older kernel sources. And, btw., one usually knows which WORLD packages are slotted and can decide by oneself which old WORLD slots aren't necessary and can clean these manually. And, btw., I personally can decide this MUCH better than a software. But for those people who don't know which WORLD packages are slotted and how many SLOTs and which SLOTs are unnecessary and can be removed etc. I think such a feature like the new --depclean behaviour would really be helpful. But, please, NOT in --depclean but in a different parameter. And I still don't see why it should be a problem to divide these two features into two different parameters. > Special-casing stuff like kernel sources (which you can download at any time > from whatever kernel mirror) doesn't make any sense. In this point I agree with you.
(In reply to comment #22) > As noted above, *nothing* is stopping you from doing 'echo ${CATEGORY}/${PF} >> > /var/lib/portage/world' in /etc/portage/bashrc as postinst hook. First, I don't know what this command does. Second, this is unnecessary work for the user and administrator - not only for me. This wouldn't be possible if this new --depclean feature would be implemented in a different parameter. > I really don't > see what are you arguing here. Telling people that they need every single > kernel source they've ever installed just because you can't deal with this > doesn't make sense. I'm not telling people that they need every single kernel source. But first, everyone know which WORLD package is slotted. This is shown by `emerge -pv <packagename>`. And then I know that I have to uninstall the old versions of these packages manually. Second, I already said more than once that I actually like such a feature which cleans old unneeded versions/slots of WORLD packages. But this really must not be done by a parameter which should just clean old unneeded dependencies because these two features are completely different. And I don't see that running emerge twice or with two parameters is so much more work. In fact it's much less work than putting every single SLOT into the WORLD file or possibly running `echo ${CATEGORY}/${PF} >> /var/lib/portage/world` or whatever. It's just MUCH more user-friendly if there was a second parameter which implements the new but different feature and makes things MUCH easier and clearer for the users.
Just to make it clear. I'm not saying that this new behaviour should be removed from portage completely. I'm only saying that this new behaviour should be implemented as a second parameter. One parameter for only one feature. And packages which are installed as a dependency of another package are different from packages which are installed directly and put into the WORLD file. This is in fact the only thing what I'm asking for.
(In reply to comment #10) > That sounds something like the --prune option which is already available. I just tried the --prune option and, yes, it is this option as Zac Medico said. So this new --depclean behaviour is already implemented in the - I guess not so well known - --prune. So it should be enough to just remove this new --depclean behaviour from --depclean. Then this feature wasn't removed completely and both different features are implemented by two different parameters. Maybe it could make sense to advertise the parameter --prune a bit more.
Another suggestion is to introduce a third - let's say - wrapper parameter which executes both --depclean with the old behaviour and --prune together for people who don't want to run emerge twice or once with two parameters.
While I agree with Jakub that the behavior of portage is excatly as advertised, I would really like the following feature: Allow to specify "all" SLOTS in the world file like: sys-kernel/mm-sources:* Otherwise it the world file will get rather messy and needs lot of maintenace: sys-kernel/mm-sources selected: 2.6.21_rc5-r2 2.6.21_rc5-r3 2.6.21_rc5-r4 2.6.21_rc6-r1 2.6.22_rc1-r1 2.6.22_rc2-r1 2.6.2 2_rc3-r1 2.6.22_rc4-r2 2.6.22_rc6-r1 2.6.23_rc1-r1 2.6.23_rc1-r2 2.6.23_rc2-r1 2.6.23_rc3-r1 2.6.23_rc4 -r1 2.6.23_rc6-r1 2.6.23_rc7-r1 2.6.23_rc8-r1 2.6.23_rc8-r2 2.6.23-r1 2.6.24_rc2-r1 2.6.24_rc3-r1 protected: none omitted: 2.6.24_rc3-r2 If a wildcard SLOT was allowed, this should fix Heiko's without the need for more parameters and without any special casing. Currently I do not know any way to exempt mm-sources from the SLOT cleanup without needing to add *22* lines to my world file. And I would need manually add a new line each time mm-sources get upgraded by emerge -u world...
*** Bug 201789 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > Can someone WONTFIX this bug? Because it's getting completely nonsensical. > Unmerging kernel sources breaks *nothing*. The kernel stays there, the modules > stay there. I'm calling shenanigans on your comment. Unmerging kernel sources *does indeed* break things. In my case, I use gentoo-sources-2.6.17-r8 and it is stable. There is no need for me to upgrade the kernel at this time. Depclean and unmberged the sources. Now I can't upgrade lm-sensors because the kernel sources are gone! Will someone pelase fix deplcean! This kind of behavior is NOT SANE!
(In reply to comment #31) > In my case, I use gentoo-sources-2.6.17-r8 and it is stable. > There is no need for me to upgrade the kernel at this time. Depclean and > unmberged the sources. Now I can't upgrade lm-sensors because the kernel > sources are gone! Oh noes! lm-sensors works just perfectly fine w/ 2.6.23 kernel, but I'm pretty sure that using a kernel that's been outdated one year ago completely rocks and is a perfect reason to stick with whatever nonsense you wish... :P
(In reply to comment #32) > (In reply to comment #31) > > In my case, I use gentoo-sources-2.6.17-r8 and it is stable. > > There is no need for me to upgrade the kernel at this time. Depclean and > > unmberged the sources. Now I can't upgrade lm-sensors because the kernel > > sources are gone! > > Oh noes! lm-sensors works just perfectly fine w/ 2.6.23 kernel, but I'm pretty > sure that using a kernel that's been outdated one year ago completely rocks and > is a perfect reason to stick with whatever nonsense you wish... :P > The issue isn't how old the kernel is it is that the sources disappear. I have the same problem with all kernel module packages when even a new revision bump happens. If I am running 2.6.23-r1 and 2.6.23-r2 comes out and I use depclean, I lose my -r1 sources that represent the kernel I am running. I now have to update just so that kernel module packages don't break. And seriously "Oh noes!" ... "I'm pretty sure that using a kernel that's been outdated one year ago completely rocks and is a perfect reason to stick with whatever nonsense you wish..."? This isn't the attitude that should be taken in any case whether you are right or not. Lets make our users feel unwanted and make all Gentoo devs sound arrogant... great attitude.
(In reply to comment #33) > And seriously "Oh noes!" ... "I'm pretty sure that using a kernel that's been > outdated one year ago completely rocks and is a perfect reason to stick with > whatever nonsense you wish..."? This isn't the attitude that should be taken in > any case whether you are right or not. Lets make our users feel unwanted and > make all Gentoo devs sound arrogant... great attitude. Yeah, oh noes! What an arrogant attitude that noone wishes to support kernels that have zillions of security bugs. :P It's whole lot much better to moan that something gets depcleaned b/c that's what the feature is for and it's so horribly hard to not use the feature...
(In reply to comment #33) > The issue isn't how old the kernel is it is that the sources disappear. I have > the same problem with all kernel module packages when even a new revision bump > happens. If I am running 2.6.23-r1 and 2.6.23-r2 comes out and I use depclean, > I lose my -r1 sources that represent the kernel I am running. I now have to > update just so that kernel module packages don't break. As I mentioned in comment #10, the recommended solution for this situation is to add the specific version of sources that you want to keep to the world file (it will be recorded as a slot atom). It the same as any other case where you want to prevent depclean from removing a specific package. This is why --depclean shows a big huge warning message when you run it.
(In reply to comment #34) > Yeah, oh noes! What an arrogant attitude that noone wishes to support kernels > that have zillions of security bugs. :P It's whole lot much better to moan that > something gets depcleaned b/c that's what the feature is for and it's so > horribly hard to not use the feature... --depclean has definitely nothing to do with any security bugs and this problem is not only related to the kernel but to every world packages. If someone wants to use a year old kernel for whatever reasons then you simply have to accept it. Do you know how he configured his kernel? Do you know if and which security bugs he has compiled into his kernel? Do you know if these security bugs are really a security issue on his own system? I guess no. So let him use the kernel version he wants. And, yes, the kernel sources are necessary to get some packages - not only lm_sensors - compiled. And it really doesn't matter if lm_sensors also compiles with kernel-2.6.23. The problem is also the time it takes to always compile a new kernel as soon as a new kernel version is out. (In reply to comment #35) > As I mentioned in comment #10, the recommended solution for this situation is > to add the specific version of sources that you want to keep to the world file > (it will be recorded as a slot atom). It the same as any other case where you > want to prevent depclean from removing a specific package. This is why > --depclean shows a big huge warning message when you run it. You've heard anything of user-friendlyness? Fact is that this new "feature" of --depclean is already done by --prune. So in the "new" --depclean there are two very different features mixed up which really don't have anything to do with each other. If someone wants to clean out his world packages he simply can run `emerge --prune` which will also remove every old kernel sources. But `emerge --depclean` is run to only remove old dependencies which were needed by other packages and are no longer needed by these packages. Btw., yesterday it happened again. I ran `emerge -uDN world`, a new kernel version was installed again, I didn't and don't have time to compile the new kernel, `emerge --depclean` wants to unmerge not only the old and no longer needed dependencies but also the kernel source. I still need the old kernel source, so I can't run `emerge --depclean` and therefore must keep the old dependencies which only waste disk space and possibly make the system more instable. And this is extremely annoying. And have you read `man emerge`? This is what it says about --prune: --prune (-P) WARNING: This action can remove important packages! Removes all but the highest installed version of a package from your system. This action doesn't verify the possible binary compatibility between versions and can thus remove essential dependencies from your system. I guess there's a very good reason why this warning is in the manpage. And I guess that some of these important packages are the kernel sources. So, please, remove the --prune features from --depclean. Everyone who wants to clean up the world packages can easily run `emerge --prune` but not everyone who needs to run `emerge --depclean` wants to clean up the world packages but only wants to remove old unnecessary dependencies. And been forced to always add a certain package version to the world file is absolutely unacceptable, fiddly, user-unfriendly and really not necessary if there these two features would be kept seperated. And again, everyone who needs to clean out the world packages can easily run `emerge --prune`. This option and only this option is there for exactly this reason.
(In reply to comment #36) > Btw., yesterday it happened again. I ran `emerge -uDN world`, a new kernel > version was installed again, I didn't and don't have time to compile the new > kernel, `emerge --depclean` wants to unmerge not only the old and no longer > needed dependencies but also the kernel source. I still need the old kernel > source, so I can't run `emerge --depclean` and therefore must keep the old > dependencies No, you *don't* need the old kernel sources to *run* whatever external kernel modules you've installed, at all. I really fail to see where did you get this nonsense from. You only need kernel sources to *compile* kernel modules and kernel itself, after you've done this, it can completely safely be wiped from the disk. > So, please, remove the --prune features from --depclean. Everyone who wants to > clean up the world packages can easily run `emerge --prune` but not everyone > who needs to run `emerge --depclean` wants to clean up the world packages but > only wants to remove old unnecessary dependencies. Once again, because it's apparently still not clear: emerge --depclean does exactly what's expected - it wipes *unneeded* stuff. And yeah, everything but the latest installed slot of virtual/linux-sources is *unneeded* for the stuff in question here, unless you've explicitely added other slots you want into world. Exactly as unneeded as any other redundant slot from any other package that --depclean would wipe.
(In reply to comment #37) > Once again, because it's apparently still not clear: emerge --depclean does > exactly what's expected - it wipes *unneeded* stuff. And yeah, everything but > the latest installed slot of virtual/linux-sources is *unneeded* for the stuff > in question here, unless you've explicitely added other slots you want into > world. Exactly as unneeded as any other redundant slot from any other package > that --depclean would wipe. I think you are mistaken. --depclean cleans unneeded /dependencies/ not /unneeded stuff/. The kernel sources package is in my world file thus they should not be removed by --depclean. --prune is the parameter to get rid of unneeded /slots/. If I wanted to get rid of my outdated /slots/ I will use --prune, not --depclean. Read your documentation, thank you.
(In reply to comment #38) > Read your documentation, thank you. I did read the documentation. Unfortunately, as your comments show, clearly reading it is not enough, you need to understand it as well. It completely doesn't matter that it's in world unless you explicitely add the redundant slots there as said in Comment #10. Otherwise they will be unmerged on --depclean because *nothing* depends on them. (And no, --prune is NOT a replacement for the behaviour you are complaining about.)
(In reply to comment #39) > I did read the documentation. Unfortunately, as your comments show, clearly > reading it is not enough, you need to understand it as well. Well, Jakub, in Germany there's a saying "Selbsterkenntnis ist der erste Schritt zur Besserung." The equivalent English saying is "A fault confessed is half redressed." I would say you haven't understood the documentation. > It completely doesn't matter that it's in world unless you explicitely add the > redundant slots there as said in Comment #10. With this behaviour it is completely impossible to maintain a system and several slots in the world file because you have to remember every single version of a package in a world file. So you are only able to remove those old version which you don't need anymore manually. But there's the --prune option to prevent this. --prune is for those cases where you need to keep older versions and want to clean these older world package versions if you don't need them later. But this is *not* possible if you add every single version/slot manually to the world file because then --prune can't know which of these version is outdated. > Otherwise they will be unmerged > on --depclean because *nothing* depends on them. No! The world file is depending on them! This *is* a dependency or at least was always meant as a dependency by portage in the past. Dependencies are only those packages which are *not* installed manually by `emerge <package name>` but *only* automatically because a package which is installed manually by `emerge <package name>` needs it. > emerge --depclean does > exactly what's expected - it wipes *unneeded* stuff. As Nicolas Doyle said in comment #38 emerge --depclean is expected to remove *only unneeded dependencies*. And world packages are *not* unneeded and generally *no* dependencies! > (And no, --prune is NOT a > replacement for the behaviour you are complaining about.) Jakub, you're completely wrong. This *always* was a "replacement" for the behaviour we're complaining about. This *was* and still *is* the function of --prune. Jakub, please, read Nicolas Doyle's comment #38 again. (In reply to comment #37) > No, you *don't* need the old kernel sources to *run* whatever external kernel > modules you've installed, at all. I really fail to see where did you get this > nonsense from. You only need kernel sources to *compile* kernel modules and > kernel itself, after you've done this, it can completely safely be wiped from > the disk. Now I know that you don't read and/or don't understand what's written here. I and anyone else haven't said that old kernel sources are needed to *run* a kernel and external kernel modules. I and anyone else talked about *compiling* and *maintaining* a kernel and external kernel modules. And this *is impossible* without the kernel sources! > Once again, because it's apparently still not clear: emerge --depclean does > exactly what's expected - it wipes *unneeded* stuff. And yeah, everything but > the latest installed slot of virtual/linux-sources is *unneeded* for the stuff > in question here, unless you've explicitely added other slots you want into > world. Exactly as unneeded as any other redundant slot from any other package > that --depclean would wipe. Again, read Nicolas Doyle's comment #38 and my comments above and at least try to understand it.
(In reply to comment #40) > No! The world file is depending on them! This *is* a dependency or at least was > always meant as a dependency by portage in the past. I of course mean the packages listed in the world file are always *needed* dependencies independently from the installed versions if you want to name world packages as dependencies. But in fact they are *not* dependencies and therefore don't have to be touched by --depclean which stands for "cleaning dependencies" which was the original behaviour of --depclean in the past.
Ok, it seems that the way to fix this problem is to start editing the world file manually. Sure, I can live with that. Let's make a world file editor to make this easier. Let's call it... oh I don't know, how about regedit. Then, just so we don't get too confused, let's rename the world file to the registry. Maybe split it up into chucks called, hives. Yea, that'll work. You think Microsoft has trademarked those terms yet? Instead of pissing and moaning, why not just fix the code. If I had the requisite coding skills, I'd do it myself. I don't, so I, and many others, have to endure this penis measuring contest.
(In reply to comment #42) > Ok, it seems that the way to fix this problem is to start editing the world > file manually. Sure, I can live with that. Let's make a world file editor to > make this easier. Once again - how about reading Comment #10? You don't need to edit anything manually.
(In reply to comment #43) > Once again - how about reading Comment #10? You don't need to edit anything > manually. Once again - this *is* editing manually. I have to add every single slot manually to the world file. If I'm doing this by editing this file with an editor or by running `emerge --noreplace` is the same and makes no difference. And with this method it is completely unmaintainable because I must remember / write down every manually added slot to be able to remove one or more of these slots when I don't need one of these older slots anymore. Without this method, with the old and useful method I don't need to make such an unnecessary efford because --depclean just leaves the world packages and all of their slots alone and I can easily remove those older unneeded world slots by simply running `emerge --prune`.
Btw., I really don't know what's so hard at it to understand. It's so easy: --depclean just removes old, unneeded dependencies (world packages are *not* dependencies) --prune just removes old, unneeded slots/version of world packages (and no dependencies) This is flexible and does everything what's needed. And you, Jakub, can still remove older kernel versions directly after an kernel update if you don't want to keep them. Just run `emerge --prune` directly after `emerge -uDN world`. Why is this so hard to understand, to accept and to reimplement?
@Everyone: Please stop discussing if this change makes sense or not. Both ways have their use cases and we're going to export them both one way or another, further comments not directly related to an implementation of a solution will just waste everyones time and motivation. Only if you don't see any comments here from me or Zac in the next 4 weeks feel free to remind us about this issue.
Four week bump. Any new information?
We've had a suggestion on the gentoo-portage-dev mailing list that's relevant for this bug: http://archives.gentoo.org/gentoo-portage-dev/msg_3bed8a21dd63a06d9bd5fad2ad2c96fc.xml We can add support to tools like eselect kernel and java-vm to configure package sets that pull in the relevant packages in order to prevent them from being unmerge.
(In reply to comment #48) > We can add support to tools like eselect kernel and java-vm to configure > package sets that pull in the relevant packages in order to prevent them from > being unmerge. Rather the other way around: implement a (single) package set that queries those tools for the current version (would need some kind of plugin system though), maybe with config options for "include all slots".
(In reply to comment #49) Or even simpler: implement a small addition to the world file syntax: see comment #28 : > Allow to specify "all" SLOTS in the world file like: > sys-kernel/mm-sources:* While I would like to see a feature like 'keep the last 3 slots', the above would be a 99% solution for me. The "eselect kernel"-solution would not work for me, as I want/need to keep all past kernel packages on that system.
(In reply to comment #28) > Allow to specify "all" SLOTS in the world file like: > sys-kernel/mm-sources:* I'd rather not use a non-standard atom syntax in the world file. As an alternative, I suppose we implement a way to make a StaticFileSet [1] that is greedy wrt slots. You could then add that set to world and it would behave sort of like a second world file that you could list your greedy atoms in. [1] StaticFileSet is documented in the html docs that are installed by portage-2.2_pre when USE=doc is enabled.
Portage-2.2 "solves" this in the following way (I'm not really sure if this is a good solution, maybe we'll come up with something better in the future): 1) create a file /etc/portage/sets/greedy (the path is up to you, but must match the filename in step 2), listing all atoms that you want to match multiple slots, e.g. "sys-kernel/gentoo-sources" (same format as package.mask) 2) add the following to /etc/portage/sets.conf: [greedy] class=portage.sets.files.StaticFileSet greedy=True filename=/etc/portage/sets/greedy 3) run `emerge --noreplace @greedy` to add the "greedy" set to "world". This may change depending on the outcome of http://forums.gentoo.org/viewtopic-t-664181-highlight-.html
*** Bug 232345 has been marked as a duplicate of this bug. ***
And what about introducing SLOT wildcard in package atom specifier? like sys-kernel/gentoo-sources:* Such entry could be added to let's say world file or in general in DEPEND section of ebuilds - that would trigger greedy pulling behaviour - pulling all (installed) SLOTs. There are some problems with such behaviour as it can't determine which SLOT is the 'latest' - so that when no SLOT is not installed at all - it could behave like default sys-kernel/gentoo-sources SLOTless non-greedy pull.
Looks like I'm not the first with such idea.
A problem with greedy atoms is that they eventually lead to dependency graph breakage when packages become so old that their dependencies are no longer available (as they are incompatible with newer versions pulled in by newer packages). For cases like this, emerge will have to automatically suggest that the user remove the old packages (since many users may not recognize by themselves that this is the appropriate course of action).
I added bug 283587, which I don't consider to be a duplicate because I have explicitly added a dependency using eselect, yet depclean STILL wants to remove the kernel source.
*bump* and +1 to modify --depclean - behavioral: # uname -r 2.6.32-gentoo-r7 # ls -al /usr/src linux -> linux-2.6.32-gentoo-r7 linux-2.6.35-gentoo-r4/ # emerge -p --depclean [...] sys-kernel/gentoo-sources selected: 2.6.32-r7 protected: none omitted: 2.6.35-r4 [...] As of today 2.6.35-r4 is the newest kernel-sources in my world, but shurely i dont want to loose the sources of my actual kernel!
Personally, I have always considered this to be a flaw in portage. Every time I do a --depclean, I do a pretend first to get a list of packages, then filter out the slotted packages, manually typing in each package name I really do want to uninstall for --depclean. It works, and it's worked ever since I've used Gentoo, but it finally became irritating enough today that I set out to find a solution. Sadly, it's been 3 years since this bug has been filed and still no real solution exists. For me however, I'm not so buffed with the kernel sources as I am with binutils and gcc. I absolutely _must_ keep previous versions on ARM, because ARM doesn't quite get the testing that x86 or other major platforms do. I can't remember the number of times I've been burned by a binutils upgrade that failed to produce a valid executable after compiling. This is why I have USE="multislot" set, and I'm thankful for it's existence. Put simply, having --depclean clean out the previous slots is not acceptable. Manually adding a separate entry for each slot in the world file is also not acceptable. Not only is it error-prone, but it doesn't help when installing a new slotted version of a package, because I don't explicitly specify the new version to emerge. Since it seems there hasn't been any progress on this bug, I'm going to try to make some patches to fix it. However, I propose the following change instead of the previously suggested methods: - Add a new command line parameter to emerge: '--slots', which modifies the behavior of '--depclean'. When '--depclean' is specified, any slotted packages are ignored and not cleaned. When '--depclean --slots' is specified, slotted packages are cleaned as well. Since this would result in a functional change to the emerge interface, I'm not sure if the Gentoo developers would be willing to accept such a modification. While I would prefer the above method, I am also willing to negate the flag, such as: - Add a new command line parameter to emerge: '--noslots', which modifies the behavior of '--depclean'. When '--depclean' is specified, the original functionality is kept, and slotted packages are cleaned. When '--depclean --noslots' is specified, any slotted packages are ignored and not cleaned. If anyone has any extra input or comments, I would be very happy in hearing them. Let's work together to make Gentoo better for everyone.
My vote is for adding the --no-slots option as it preserves current behavior but adds the functionality for those who need and want it. A change like this doesn't seem like it would be too invasive (of course I haven't verified this). Let me know if you would like someone to help test the patch.
(In reply to comment #59) > - Add a new command line parameter to emerge: '--slots', which modifies the > behavior of '--depclean'. When '--depclean' is specified, any slotted packages > are ignored and not cleaned. When '--depclean --slots' is specified, slotted > packages are cleaned as well. It's important to maintain symmetry between update and depclean operations, so that update operations pull in the same packages that depclean operations do. When this symmetry is properly maintained, it ensures that `emerge -uD --with-bdeps=y world` pulls in ever possible update, and that depclean removes anything not pulled in by the update command. Given this symmetry requirement, a possible solution would be a --greedy-world option which makes unspecific world atoms greedy for all installed slots (for both update and depclean operations).
However, note that such a --greedy-world option could cause issues when trying to solve blockers during updates. For example, kde-base/kde-meta updates always blocks older slots. The depgraph._greedy_slots() method already has some code that prunes older slots in case of blockers, and that logic could be reused in the implementation of --greedy-world.
(In reply to comment #61) > Given this symmetry requirement, a possible solution would be a --greedy-world > option which makes unspecific world atoms greedy for all installed slots (for > both update and depclean operations). Heh, I really was hoping for a more simpler implementation like I described above, but I can understand the reasons behind it needing to be properly implemented and not just a hack. As an initial implementation, just so that we at least have something to start with, I'll first make a patch which follows the '--no-slots' functionality. From there (and after I've come to better grips with portage's source), we can expand on it and get it implemented properly. Thanks for your input! I'll be sure to keep the symmetry in mind, as I originally didn't even consider --update as being part of this issue.
(In reply to comment #63) > Heh, I really was hoping for a more simpler implementation like I described > above, but I can understand the reasons behind it needing to be properly > implemented and not just a hack. The --greedy-world option that I've described should only require some minor tweaks in the depgraph set handling. The most complex part is the blocker handling, but that's already written in depgraph._greedy_slots().
OK, fair enough. I'll give it a shot.
Wouldn't it be possible to have more specific handling for things that have eselect modules, such that the selected version is never removed? That would seem to me like a more elegant solution (though I don't know how integrated eselect is).
(In reply to comment #66) > Wouldn't it be possible to have more specific handling for things that have > eselect modules, such that the selected version is never removed? That would > seem to me like a more elegant solution (though I don't know how integrated > eselect is). The interface needs to be specified in PMS. See bug 283587.
I think a better solution would be to make "persistent" ebuilds/eclasses(not familiar with those though); meaning that you can select sys-kernel/git-sources in world file, but when emerging a specific kernel source it will record =sys-kernel/git-sources-<version> in the world file. Simple and perfect solution that can also work for java-vms and other packages to act like that.
(In reply to comment #68) > I think a better solution would be to make > "persistent" ebuilds/eclasses(not familiar with those though); meaning that you > can select sys-kernel/git-sources in world file, but when emerging a specific > kernel source it will record =sys-kernel/git-sources-<version> in the world > file. > Simple and perfect solution that can also work for java-vms and other packages > to act like that. We already have support for SLOT atoms in the world file. For example: emerge --noreplace =sys-kernel/gentoo-sources-3.1.1 That will add a sys-kernel/gentoo-sources:3.1.1 SLOT atom to your world file.
#69, i geuss you do not understand the point i was trying to make. I know emerge supports slot atoms, my point is that kernel ebuilds should record its own package as a slot atom in the world file so that when you have non slot kernel in the world file it will keep updating on emerge --update and keep all kernels, including the eselected kernel. We can create a use flag for this. The next step would be to warn/error the user when it tries to --deselect/--unmerge a '/usr/src/linux' linked kernel source. This will solve this bug.
Honestly, I think the right thing to do here would be getting rid of that eselect thing and replacing it with something on top of package manager. Then, the dependency tree could become explicitly aware of user's choices and portage would not depclean the currently used kernel.
Hmm, or even better. I'll allow myself to close this one and move the discussion to the more general bug to avoid people adding comments to the wrong bug (like I did :)). *** This bug has been marked as a duplicate of bug 283587 ***
Reopening bug closed by developer with good reason without any comment is considered very impolite.
The comment would have followed, if you would have waited a few seconds.
This bug is the older bug and not a duplicate of the newer bug #283587. This bug has nothing to do with eselect. Both bugs may be related to each other in some respect, but they are not duplicates. That's why another developer has set bug #283587 under "Depends on" as you could have seen.
Oh, and, btw., I'm the reporter of this bug. So I guess reopening this bug report even without a comment by the reporter wouldn't have been this impolite. On the contrary I consider closing this very old bug just as a duplicate of another very old, but newer bug impolite.
