Keeping an installed package the way it is (no changes)

[LIsLinuxIsSogood]

I would like to know how to basically tell the package manager to neither update nor remove a certain package when I run system update or clean function. I know this could be done in a few different ways, but because of my own hesitancy to want to add lines to the make.conf (1 way I thought of that would work, within the line for EMERGE default options).

However, I am trying to follow the routine way for keeping up to date system, which includes running depclean to remove all the unnecessary dependencies, and also every time before that perform a emerge --update --deep ..... for the world set. The package is wine. And while I am sure that there is nothing unique about the package, the fact that it works with the various other software that I've installed is enough for me.

I used the atom wine-9999 to install it. So if I want to lock in the current build, and not rebuild the next time and also not have it removed when I next run depclean on the system which is what would happen if I simply remove that package from the world set, then what other options do I have there? I have a slight bias for not using the package.mask since I like to leave that for "real problem" packages and not this example of just a preference for a particular build.

[charles17]

Copy it to your custom ebuild repository and add a line to your /etc/portage/package.accept_keywords file:

Code: Select all

=app-emulation/wine-9999::<your repo name> **

[krinn]

However, I am trying to follow the routine way for keeping up to date system, which includes running depclean to remove all the unnecessary dependencies

depclean is just a space saver ; and to do so, it remove what depclean think or consider as "useless", but it could be tricky to find what is "useless" on a system, for depclean it's just "if nobody depends on this package and this package is not in world" -> useless.
And it's tricky because your kernel-sources-1.0 are not use by anyone any more for depclean because emerge has emerge kernel-soures-2.0, but you are still using kernel-sources-1.0, and without them, you will have complain from packages that want use them.

If you don't depclean :
- building package that use the crap: these are buggy package ebuild and they should be fix, if an old package is there (one new and one "useless" old version), packages should use newer version, and if it use the old one, it's a bug in its building system.
- security issue: if a package is "useless" and have cve issue, cve tool will tag it, but if the ebuild wasn't remove and mask, you will not see any complains, it's again a fault, it was mask for cve issue, and it hasn't been taken off the tree.
- if the "useless" crap depends on something and is broken, revdep-rebuild will tell you.
- If the "useless" crap have no more ebuild, many tools (including portage) will point that to you.

In real, depclean will more help you when you are building a package that emerge is not handling, because the "useless" thing is in your system and emerge isn't handling the building, the package you are building may find and use the old crap.
It's your own fault, if you build package Y and you didn't add its dependencies yourself ("Z"), without the "useless" "Z", it would had complain, and because an old "Z" is in your system, it will not and build with the old Z ; but it's still your fault, if you had properly done it, you would had seen it need "Z" and had add "Z" (so newer version) to make it happy.

Having package "Z" old and crap (useless) in your system is a 0 issue for portage, if anyone want use "Z", portage will upgrade it prior anyone could use it.
So depclean is NO MORE than a space saver, and really not a tool to keep your system sane (it's a fucking bad concept everyone carry on).
And because of tricky tagging of what is a "useless" package, depclean you will more mess your system than someone not using it at all.

Using depclean, you are just saving yourself from buggy ebuild that would build against an old package without having it has dependency, i admit it could help, but it's a flaw in the ebuild, not your fault because you don't use depclean (but you may consider that even not your fault, the problem appears and you might not enjoy it ; and depclean would had save you from the issue)
At least, because of tricky handling and mistake depclean could do: in no way depclean should be consider a "routine" tool, it's a special tool that could harm your system just to save a few space.
If you are a depclean mad user, at least enable binary package to saved you from its bad usage.


After my rant against depclean:
If anything is set in world, portage will not upgrade it, and depclean will not remove it. It mean adding wine-9999 (not wine, but wine-9999) to world will "nearly" do what you want (it's a live ebuild, its source depends on the tarball source in use, and if emerge update the ebuild, it will also update its tarball source MD5, and any rebuild will download the new tarball and build sources that are no more the ones you were using). It's also perfectly valid to have a package without version and a versioned version in world for slotted package
For non live ebuild, its source tarball MD5 shouldn't change, and as such, portage will keep it as-is, and issue warning when the ebuild is no more in the tree.
For live ebuild, charles17 solve is the best to really keep the tarball source frozen.

[NeddySeagoon]

LIsLinuxIsSogood,

You really don't want to do this. -9999 tells that you are using WINE from the head of repository ... as it happens.
As WINE is developed, what the -9999 ebuild builds will change, so you can't even rebuild the wine you have today with the -9999 ebuild in your local overlay. You would need to modify the ebuild to check out a fixed commit.

What happens when the libraries that wine uses are updated?

Eventually old libraries will be removed and your system will become more and more difficult to maintain.

You need to update from time to time to stop the bitrot described above.

Code: Select all

emerge --exclude app-emulation/wine  ... 

can help. There is no need to update every package every month.
You can add the --exclude list to make.conf but don't forget to keep an eye on what portage would do if you let it.

[mv]

so you can't even rebuild the wine you have today with the -9999 ebuild in your local overlay

You can, if you set EVCS_OFFLINE=yes in your make.conf.
In this case you must not forget to set EVCS_OFFLINE="" in your environment if you really want to rebuild the newest version.

Anyway, I do not understand the original question: Why do you not want to put =app-emulation/wine-9999 in your world file? This would fix all your problems with depclean and dependencies. And the correct way if for some reason you want to avoid updates is to mask higher versions locally.

[dilfridge]

Not using depclean is the fastest way into upgrade hell.

[LIsLinuxIsSogood]

How would masking versions for this package work? I really would prefer to have wine update only when I tell it to. Even though I think that may be the case anyway, and actually I may have changed some global flags that were on the app-emulation/wine package install. I think that is why it wanted to install again (guessing).

[ct85711]

Generally, when you install a package and specify the exact version to use; portage will also record that version into your world file; meaning it will want that exact version.. By coping that ebuild file (and any applicable patches) to a local overlay, that will ensure that version will always be available; and you didn't need to mess with masking and unmasking...

[LIsLinuxIsSogood]

K, I like the idea of local repository -- going with that...I have some # of other software packages as well that could also be included in the local repo that would include many things I've installed with the -1 option as a way of not having to mask the packages but to keep a specific version. I know it isn't the best practice according to others, but this is a preferred method for me that does not then create the need to see which packages are available, therefore I really like this solution better.

Just one more question:

Does emerge --depclean become aware of all repo's when removing, and will any packages that I add to the set be able to be kept out of either emerge @world or emerge --depclean?

Thanks to charles17 for the suggestion, and ct85711.

[charles17]

Just one more question:

Does emerge --depclean become aware of all repo's when removing, and will any packages that I add to the set be able to be kept out of either emerge @world or emerge --depclean?

Having e.g. x11-libs/gtk+:3::mv in your world file would allow updating gtk+:3 only from the mv ebuild repository. And never get accidentally overwritten by gtk+:3::gentoo.

[krinn]

Not using depclean is the fastest way into upgrade hell.

That's false, by my experience, i just use depclean like 1 time / 6 months or more, and i have no trouble using gentoo.
That's also false by logic: to get any upgrade trouble, the "useless" package have to be upgrade, but it's because it is tag as "useless" that portage will always ignore it except if you specify it ; and i see no real reason for someone to do so.

As soon as the package become a dep of another or the user add it to world it's no more "useless" and portage will look at it for upgrade.
The upgrade complexity is equivalent to a new package, which is always easier than an existing one.

Thank you for showing what i said it's a fucking bad concept everyone carry on
And with your dev tag, your voice have strength, but sorry, depclean is more a space saver than a critical tool for maintenance, with no better usage than eclean (and nobody keep recommanding running eclean every times).
Even its name should hint user it's "dep" "clean", it's not "save" "yourass".

[ct85711]

Having e.g. x11-libs/gtk+:3::mv in your world file would allow updating gtk+:3 only from the mv ebuild repository.

The issue on just having x11-libs/gtk+:3::mv is that, it allows upgrade inside that slot, which the OP doesn't want... Where as if you use =x11-libs/gtk+-3.22.16::mv; you are saying you want exactly that version to portage, and portage won't try to upgrade until you tell it too...

[LIsLinuxIsSogood]

I agree with krinn, but interesting that it seems like a tough thing to bypass depclean alrogether, but i agree it has got to be maybe truly limited in its features.

Also ct, the problem with your suggestion is the package as a local copy already never will update alone itself because it is not synced to a tree, and is a local overlay

[ct85711]

tell the package manager to neither update nor remove a certain package when I run system update or clean function.

Yes, that is correct, as that is what you are asked for in the original post; in that the package DOES NOT GET UPDATED. This doesn't prevent you from updating it later on, when you want to; just copy the new ebuild to the overlay; and tell portage to install the new version. This doesn't mean the portage tree won't get update, as those packages would still be following the main tree. So when you want, you can easily look in the portage tree to find out which new version of wine you want to use next.

[LIsLinuxIsSogood]

I'm no expert with ebuilds having had little experience with making any serious changes to the ones in either the main repo or through overlays but isn't the live ebuild (ending in 9999) a problem in the sense of the example (from above with version number and entering it into the world set would be impossible for portage to be aware of the actual build it is doing due to the packaging of Wine, no? That makes it kind of difficult in some respect to keep on top of in this case I am wondering maybe the best thing to do would be to tell portage to stop syncing the tree for this particular package that seems to be working well at the moment. Any further thoughts or suggestions are welcomed.

[LIsLinuxIsSogood]

Also, as we can sort of agree that depclean is occasionally useful, how do most packages become unmerged? Is emerge --unmerge the best for removing, maybe after a --pretend depclean would help to run beforehand.

[Hu]

emerge --unmerge will, by design, not respect package dependency information. It is a useful tool when you need to forcibly remove a package and are willing to accept the collateral damage caused by that removal. Improper usage can remove important packages, leaving the system broken or otherwise difficult to maintain. Use it only when emerge --depclean refuses to proceed and you know why the resulting collateral damage is acceptable (most commonly, the answer is that the package(s) broken by --unmerge are not needed in the near term, and you anticipate being able to repair them before they are needed).

[krinn]

revdep-rebuld and --buildpkg are the things that will help you the most.