Removing a package without actually removing any files

flatmodel · n00b Joined: 01 Mar 2013 Posts: 26 Location: UK

For various reasons, I need to keep an old version of Perl installed. To achieve this, I have masked off any and all Perl versions that would otherwise update the Perl installation that I already have. This works fine as far as it goes, but it's causing me problems when I try to do an

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

The default location for the system fingerprint is at /var/db/pkg, but removing all traces there is at least against good practice. I've never had to resort to that, and I'm reckless.

IIRC, perl can have multiple versions installed simultaneously. If you want to protect a given version, add that to world and make a local ebuild. You will likely run into issues in the long run as portage advances - this happens to me trying stay on kernel 4.19.114, and a couple other deprecated packages that just work, while newer versions just don't.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

Perl is not slotted, so you cannot have multiple versions co-installed. Python is slotted, though.

I think the best course of action would be to update Perl. The second best course would be to keep it installed and masked, so that Portage can at least warn about the problems this causes. If OP were to successfully orphan Perl, then Portage would start trying to install a modern Perl over it as soon as anything needed Perl. That would just make the situation worse.

figueroa · Posted: Thu May 26, 2022 4:08 am Post subject:

Why do you need to keep an old version of perl? Doing what you want creates a dead end that will result in a broken system. What is the problem that causes this issue for you? Whatever the problem is, there is likely some other solution.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

I know of a way that would probably achieve the OP's goal of not updating Perl and also suppressing Portage's attempts to update Perl. However, it is a horrible hack, and I agree with figueroa. The proposed plan is almost certain to cause more problems than it solves.

I strongly discourage doing as OP describes. However, OP: if you want to go down this path, change the installed Perl to have a different slot, so that you can install a newer slot 0 perl. Create an overlay that offers a sufficiently high versioned perl ebuild that installs no files, and is in slot 0. This will satisfy Portage, without uninstalling or orphaning any files. I fully expect you will get weird breakage the next time something asks for a modern Perl, wrongly believes you have it due to the empty perl ebuild, and then uses modern Perl features in your outdated Perl install.

Zucca · Posted: Thu May 26, 2022 1:46 pm Post subject:

If I'd need an older version of Perl then I'd probably copy the ebuild to a local overlay and modify it so that it would get installed in some other location (kinda slotting it), thus avoiding file collisions. Then when running a program that needs this older perl version I'd need to modify the PATH in the current env.

This way other (perl) things would continue to work in my system while still having the old perl installed.

But since perl isn't slotted by default, there must be reason for it? I could be tricky to slot perl. I'm no perl expert by any means, so I'm just guessing here.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

flatmodel · n00b Joined: 01 Mar 2013 Posts: 26 Location: UK

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

If it is really the case that nothing else needs a newer Perl, then using /etc/portage/package.mask to tell Portage not to upgrade Perl should suffice. No need to play any elaborate tricks. This will generate a diagnostic the first time an ebuild you want has a declared dependency on a newer Perl, at which point you can reevaluate whether to keep an old Perl (and forgo that ebuild), give up the daemon, or fix the daemon.

figueroa · Posted: Thu May 26, 2022 3:58 pm Post subject:

Why not try to mask >=dev-lang/perl-5.33.0
If nothing really needs a higher version, portage should be satisfied.

Are you committed to running Squeezebox server under Gentoo. Could you run it under a Debian stable distribution and run it in a virtual machine? The current version of MX-Linux which is 21, is running perl 5.32.1-4+deb11u2, and will have LTS support through 2026.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

antonellocaroli · Guru Joined: 11 Aug 2016 Posts: 510

If it is only for logtechmediaserver there is no need to maintain an old version of perl...

I'm not an ebuild expert (some expert will probably find some errors) but I run this on a local overlay and it works...

https://github.com/antonellocaroli/GP-overlay/blob/master/media-sound/logitechmediaserver-bin/logitechmediaserver-bin-8.3.0_pre20220507.ebuild

you should change something... like sox-dsd in sox...

basically delete the perl included in LMS and create a link to the perl installed on the system....

update HASHID and BUILDID

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

Don't edit anything in /var/db/pkg!

I was just remarking as an academic point, one could erase all traces of a package from there. In hindsight, portage would figure out the package was gone and try to reinstall it.

I've kept a few deprecated package versions by masking newer and keeping an ebuild for an older version in local overlay. That would be my first resort in your spot.

flatmodel · n00b Joined: 01 Mar 2013 Posts: 26 Location: UK

[quote="cboldt"]Don't edit anything in /var/db/pkg!

Don't worry, I haven't gone down that route! :lol:

I've removed anything that might refer to perl, with the exception of the interpreter itself, and I get this...

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

All the versions of perl in the gentoo repository are 5.34. Portage has no alternative unless you give it one.

If you still have perl-5.32 installed, a copy of the ebuild for that is in /var/db/pkg/dev-lang/perl-*

Do you have a local repository? I keep one at /var/db/repos/local for a handful of programs deprecated by Gentoo, but in use on my systems. Put a copy of the perl-5.32.x.ebuild in /var/db/repos/local/dev-lang/perl -- you'll also have to call on `ebuild` to create a Manifest file in /var/db/repos/local/dev-lang/perl and there is probably a need for some patch files. You'd have to hunt around to find those.

You also have to tell portage you have a local repository. That's done in /etc/portage/repos.conf. More than one correct way to do that, I use one file to list all the repos(itories).

That in combination with your masking of versions 5.34 is how to stall your system at a deprecated version. As noted before, there will be issues of various types in the long run. I've ebuilds fail due to deprecated EAPI (I just change the ebuild to refer to a newer EAPI), deprecated *.eclass (I put the derecated eclass file into the local repository), and dependency failures.

Edited to add: the dependency failures that you note probably exist because some other package depends on them. Pretend to remove each and you'll see where the dependency lies. For example ...