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:

[krinn]

[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.

[mv]

[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]

[krinn]

[ct85711]

[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]

[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.