SOLVED ! moved ebuild from overlay to local overlay.

[CooSee]

using ungoogled-chromium from pf4public - version 142.0.7444.162_p1 was removed and *.175_p1 became stable.

don't need the new one atm - takes a long time to compile, more than 8 hours

i copied the old one one to my local overlay - now portage is complaining that the old version is not in the database.

is there a way to tell portage to just add it to the database without re-emerge ?



EDIT: sorry guys - found a solution - changed the Repo entry in /var/cache/binpkgs/Packages

EDIT1: also changed Repo to my local overlay in /var/db/pkg/www-client/ungoogled-chromium-142.0.7444.162_p1/repository <<< if you also use buildpkg FEATURES.

[rab0171610]

Someone with more experience or expertise in this area will probably correct me but
In /var/db/package/www-client there should be a parent directory for the ebuild.
You might be able to back that directory up somewhere and experiment by carefully editing the file 'repository'.
Change the repo name in the file from gentoo to localrepo or whatever the name of the current repo is.
There might also be a file name REPO_REVISIONS. The word gentoo may need to be changed there too (unlikely).
If that doesn't work then you can restore the original directory.
This is assuming the ebuild is for the exact same version you currently have installed, that it is installable -- is in the correct directory i.e. /var/db/repos/localrepo/www-client/ungoogled-chromium/ and has a regenerated ebuild manifest.

[rab0171610]

Don't be sorry. I have encountered this situation myself and always just reinstalled it. It is irritating when it is the exact same package that is already installed but only the ebuild repo has changed. I would still like to hear from someone on what is considered the best practice in this situation.

[CooSee]

exact same package

this must be or it won't work, i assume.

[sam_]

Don't be sorry. I have encountered this situation myself and always just reinstalled it. It is irritating when it is the exact same package that is already installed but only the ebuild repo has changed. I would still like to hear from someone on what is considered the best practice in this situation.

OP was talking about avoiding an upgrade between *162_p1 -> *175_p1, no? You're talking about something else (either something like changed-deps, or where two repos provide a package and you're using --newrepo which is not on by default).

[rab0171610]

No, unless I misunderstood, I believe I am discussing the same thing.
Package is installed from ::gentoo repo but later that same ebuild/version number is copied over to a local repo, for example:

Package version that is installed gets dropped from gentoo repo, higher version is stabilized.
User does not wish to upgrade, wishes to temporarily keep the lower version.
Higher versions are then masked.
User copies ebuild for lower version which was dropped but is currently installed to a local repo.
User does not want to reinstall the package.

Does portage recognize a currently installed package when the repo where the ebuild is located is no longer the same as when the package was installed?
i.e. www-client/chromium-142.0.7444.162_p1::pf4public -> www-client/chromium-142.0.7444.162_p1::localrepo

Or does it complain and user would need to reinstall the package so that the portage database for the installed package reflects the new repo name/location. www-client/chromium-142.0.7444.162_p1::localrepo does not match the installed version, www-client/chromium-142.0.7444.162_p1::pf4public because even though they are the same package version, the repo where the ebuild is found has changed.

Other than editing the file /var/db/pkg/www-client/ungoogled-chromium-142.0.7444.162_p1/repository to change the word pf4public to localrepo, is there a better way to have portage understand the currently installed version (*::pf4public) should now be associated with the same version from a new repo * ::localrepo without reinstalling the package?

If I am mistaken or misunderstood, I apologize.

[edited for clarity]

[sam_]

Oh, I see what you mean! Thanks for explaining.

[CooSee]

yes, exactly.

because the database entry is still the old one - if it's possible, to tell portage via --emerge option, e.g. --CLO (changed_to_local_overlay) --include www-client/ungoogled-chromium-142.0.7444.162_p1 that only the overlay has changed and everything else is still the same,

without recompiling, only to update the database.

[rab0171610]

yes, exactly.

because the database entry is still the old one - if it's possible, to tell portage via --emerge option, e.g. --CLO (changed_to_local_overlay) --include www-client/ungoogled-chromium-142.0.7444.162_p1 that only the overlay has changed and everything else is still the same,

without recompiling, only to update the database.

Thanks for confirming that we are on the same page CooSee. I have found myself in this situation often over the years and have always just reinstalled the packages to satisfy portage but I would rather just edit the database and change the repository name. Normally this would not be a concern, but as you pointed out for long build times or when building on slower machines it would be easier to avoid unnecessary rebuilds.

So the question remains . . . Is carefully editing portage package database files manually the only way to prevent an unnecessary re-installation (and thus subsequent resulting rebuild) of a currently installed package when the only change is that the exact ebuild used to install that package has been moved to a local repository?

I am glad it worked for you but I hesitate to recommend that to someone else. I don't want to suggest that users bypass portage by manually editing files but in this case I see the benefit if it avoids unnecessary re-installations.

[CooSee]

- i do NOT recommend this -

Backup before, of course

[rab0171610]

- i do NOT recommend this -

Backup before, of course