Handling ports (recursively and obsolete)

[jwhendy]

Hi,


I feel like I've searched all over for a good answer to this, but not found one. I'm looking for the best practice for removing a port and all it depends on. The only tool I know that does this is nonstandard - portupgrade. It's '-r' option is downward recursive: remove pkg x and all packages it depends on (iirc, only if they are not depended on by something else).

pkg_delete's -r option only deletes package x and all packages that depend on it. Maybe other users' opinions will differ here, but I never really remove ports from the bottom down... I remove them how I install them - TOP to bottom.

In other words, I'm looking for a way to remove a port and every dependency that was installed with it JUST how I installed it.

I also have not found a good solution for figuring out what packages are unneeded anymore. People refer to pkg_cutleaves and in the same sentence say it can really be detrimental and not a very good tool. I know I can use portmaster -l and try to figure out which ports aren't depended on and don't depend on anything - is that the best way?

Are there any homebrewed scripts that search depends lists? I am fairly new and don't know how to utilize the full extent of the ports to use their own tools to do what I want - e.g. using the depends lists of the ports themselves to tell me something.

So, I guess there's two questions in one post here, both related to ports management:
- What do I do when I want to remove a package and all that it depends on. Best ports practice? I also would prefer to stick with portmaster vs. the portinstall toolset.

- What is the best way to remove ports that aren't depended on anymore and that you really don't need? Stale ports I suppose... Is portmaster -s the best way or are there other ways?

Any other tips used by those in these forums would be greatly appreciated. The Handbook and these forums have been helpful to an extent, but I feel that I'm still always left unsatisfied with the tools available, maybe because I don't know how to use them properly!


Thanks,
John

 

[Mel_Flynn]

Don't believe the hype!

People refer to pkg_cutleaves and in the same sentence say it can really be detrimental and not a very good tool.

FUD. This is the best way to do top-down package removal. As with most things in FreeBSD, you are allowed to do things detrimental to your system if there's a safe way to do it, because you're expected to know when it is.

People thinking they know, shoot themself in the foot and blame the gun.

By default pkg_cutleaves is interactive: you control it's actions. Using flags that disable it, is one example of shooting yourself in the foot.

Also, complaints involve "but it deinstalled foo and I need foo for bar". The two main causes for this are:

1. You don't need foo, only to build bar and is thus safe to delete
2. You have used tools like portupgrade in the past that corrupted /var/db/pkg. Using a consistent /var/db/pkg is a prerequesite.

 

[DutchDaemon]

pkg_cutleaves is detrimental in just one way: "Hey, it seems that I don't need any of these ports, because pkg_cutleaves says so!". Oh, and acting on it.

 

[Mel_Flynn]

No, then you might as well run non-interactively. If you can't determine yourself what leaves you need, you shouldn't be uninstalling software in the first place.

 

[jwhendy]

Thanks for the input; I'll check out pkg_cutleaves in more detail. While I agree that the user should know what he/she is doing, I also think this can be prohibitive for relative newcomers like myself using it at all without reading everything in existence.

I've learned as I've gone: rented some library books to learn about what's in various directories, what certain files do, setting up my configuration for make, etc.

The only thing I disagree with, in some ways, regarding pkg_cutleaves is that I didn't have to know what ports I needed when I installed; make did that for me - checking dependencies and my environment. If a dependency was there, make just went to check for the next one; if not, it was built.

Therefore, when I go to remove a port, why don't I have the option to remove everything that make built in the first place EXCEPT those things that are listed as a dependency for something else. I think that would be somewhat logical.

Also, as a newb, how do I know what depends on what? Do you advanced folks out there keep a running list of everything every program depends on? Do you go to remove a port and then check every depend of that port by hand to see if another port depends on it too? I guess I haven't figured out how this aspect of ports management is supposed to work. You've said I should know, as the user, what ports I shouldn't remove... but how am I supposed to get that info? 'Portmaster -l'?

Is it in /var/db/pkg? BTW, how DO I keep that up to date and from being damaged by things like portupgrade and family? How to I keep that consistent? I searched the entire freeBSD handbook for 'var/db/pkg' and only found four hits:
- 4.4.4: '...all package info is stored in /var/db/pkg'
- 4.5.4.4: 'portmaster uses info in /var/db/pkg
- 14.14.1: mention of it with respect to security advisory 'AFFECTS' field
- 24.2.3: deleting pkgdb.db when updating freeBSD


-John

 

[DutchDaemon]

pkg_info(1) will be of interest, esp. the -r and -R flags. As for /var/db/pkg: you don't need to do anything with it. It is read and maintained by port maintenance utilities and the make process. All dependency information is in /usr/ports/INDEX* (one line per port), and easily printed by % make pretty-print-build-depends-list and % make pretty-print-run-depends-list in any port directory. Note that pkgdb.db is used by portupgrade and its tools (like pkgdb) only.

 

[jwhendy]

pkg_info(1) will be of interest, esp. the -r and -R flags.

NICE! I was unaware of those flags! Could I redirect/pipe those somehow into pkg_delete? I guess what I'm trying to get to the bottom of is the 'best practice' for these types of things. I'd rather not learn one way and have it be a faulty method...

For experienced users,
- what's your preferred method of removing a port if you want it and all dependencies gone?
- how do you track down and remove ports you no longer need (used to be depended on)?
- once it's gone, what else do you clean out? distfiles?
- how do you keep your /var/db/pkg up to date?

Stuff like that is what I'm aiming at understanding.


-John

 

[DutchDaemon]

I don't know whether there are 'best practices' for any of those activities. I shun best practices, anyway.

I hardly ever delete installed ports, unless I need to get rid of some major application (as in: footprint) because I'm bored with it or switched to an alternative. Then I'll usually check out what came with it and get rid of those (using % pkg_info and % portmaster -L and such to find out what depends on what).

I'll have a look at leaf ports (% pkg_cutleaves, % portmaster -L) now and again, but I can hardly be bothered about pinpointing ports te remove. It's not like they overflow my drive any time soon. I run % portmaster -s sometimes, and if I go too far % portmaster --check-depends will get me right back on track.

Also, depending on my mood, I will use % pkg_delete (-f), and use % portmaster --clean-distfiles (used to use portupgrade (% portsclean -CDD)) to clean out stale distfiles, or I'll just run % make deinstall distclean in the port directory.

There are so many ways to achieve the same goal, it would be boring to just use one

I don't keep /var/db/pkg up to date, portmaster/portupgrade/pkg-* are 'middleware' for that. I hardly even look there, maybe only to track down what an installed port brought with it in terms of dependencies it installed (% ls -lart is your friend).

For easy reference:
portupgrade(1)
portmaster(8)
pkg_cutleaves(1)
pkg_delete(1)
pkg_info(1)
ports(7)

 

[kamikaze]

WARNING: The following post is only there for reference, the advice given is WRONG!

You can use [cmd=pkg_delete]-r[/cmd]. This will delete a package and all packages it depends on, unless they are required by another package.

 

[jwhendy]

You can use [cmd=pkg_delete]-r[/cmd]. This will delete a package and all packages it depends on, unless they are required by another package.

I don't think so... from the pkg_delete man page:

-r Recursive removal. In addition to specified packages, delete all packages that depend on those packages as well.

pkg_delete -r packageName, then, deletes packageName and all packages that depend on packageName. This is what I think of as 'upwards recursive' - packageA depends on packageB, and pkg_delete -r packageB goes up the chain to remove packageB as well. What I want is 'downwards recursvie' - pkg_delete deletes a 'top level' package and all of its dependencies, except those depended on by something else, e.g. packageA depends on packageB and packageC. pkg_delete [option] packageA deletes packages B and C also.

I believe the man page option for that type of option would read more like the man pages for pkg_deinstall:

-R Deinstall all those packages required by the given packages as well.

I could go with the portupgrade suite, but I'd like to avoid it for the sake of simplicity if possible. I used to use it but then migrated to portmaster instead since it doesn't have the dependencies.

I'm thinking aloud, so I could be wrong, but I'm near positive that pkg_delete -r will not accomplish what I'm looking for. I need the reverse of how 'make' or 'portmaster portname' builds ports - the port itself and everything it depends on. When I remove it, if and when I want to, I want the port gone as well as all the depends I don't need as a result of not having the port around anymore.


-John

 

[kamikaze]

I'm sorry. How very unfair of pkg_delete to inverse the meaning of -r and -R. I thought that was at least consistent within base package tools.

I'll write a shell script for the missing functionality and include it in sysutils/bsdadminscripts. I already have a well working sorting algorithm for dependencies, I'll just have to make it use pkg_info instead of the INDEX. This shouldn't be too much work.

 

[jwhendy]

I'm sorry. How very unfair of pkg_delete to inverse the meaning of -r and -R. I thought that was at least consistent within base package tools.

I'll write a shell script for the missing functionality and include it in sysutils/bsdadminscripts. I already have a well working sorting algorithm for dependencies, I'll just have to make it use pkg_info instead of the INDEX. This shouldn't be too much work.

Cool! That would be awesome. I'm pretty new, so I've just been digging around trying to find my way. In the process it's been a bit tricky to figure out exactly how to do these things, so I'm grateful for any input. It helped to just to hear about how other people have been doing things.

I wish this was somehow incorporated into make deinstall; it would seem that if make can figure out what dependencies are needed and compile them, make deinstall could remove those same dependencies (checking against what else depends on them).

Thanks again.


-John

 

[kamikaze]

The purpose of [cmd=make]deinstall[/cmd] however is to force delete a package so you can install a newer version afterwards. To delete all the dependencies would be counter-productive.

I never missed that functionality, because I use pkg_cutleaves to delete unwanted packages.

 

[jwhendy]

Good to know.

I'll be looking into pkg_cutleaves as well. The man page references running pkgdb first... is that necessary? If so, that means pkg_cutleaves somewhat requires the installation of portupgrade as well?


-John

 

[kamikaze]

Good to know.

I'll be looking into pkg_cutleaves as well. The man page references running pkgdb first... is that necessary? If so, that means pkg_cutleaves somewhat requires the installation of portupgrade as well?


-John

I never did that. You could run [cmd=portmaster]--check-depends[/cmd] as well. Any way I think this statement is there back from days when [cmd=]portupgrade[/cmd] was the dominant ports maintenance tool.
I remember that it was often causing problems with my package database and I got into the habit of running [cmd=pkgdb]-F[/cmd] every time before and after using [cmd=]portupgrade[/cmd].

Nowadays [cmd=]portmaster[/cmd] very rarely causes such problems and I did not run [cmd=portmaster]--check-depends[/cmd] for months.

 

[jwhendy]

Nice. Duly noted. I think portmaster and pkg_cutleaves will take care of everything then.

Thanks for the input!


-John

 

[Erratus]

In other words, I'm looking for a way to remove a port and every dependency that was installed with it JUST how I installed it.

If you would deinstall just how you installed you might deinstall dependencies still required by other ports.

Any other tips used by those in these forums would be greatly appreciated. The Handbook and these forums have been helpful to an extent, but I feel that I'm still always left unsatisfied with the tools available, maybe because I don't know how to use them properly!

I read that you use portupgrade so the following might NOT be a solution to you cause portupgrade and portmaster should not be used parallel. Choose one of them but not both.

You might look at portmaster -e as it uninstalls ports and their dependencies but keeps those required by other ports.

Disclaimer: portupgrade and portmaster are not part of the base OS. Therefore advocating the use of non-standard tools might "annoy" (!sic) forum moderators.

 

[jwhendy]

If you would deinstall just how you installed you might deinstall dependencies still required by other ports.

That's why I also posted this above:

I wish this was somehow incorporated into make deinstall; it would seem that if make can figure out what dependencies are needed and compile them, make deinstall could remove those same dependencies (checking against what else depends on them).

I read that you use portupgrade so the following might NOT be a solution to you cause portupgrade and portmaster should not be used parallel. Choose one of them but not both.

I meant to say that I have used portupgrade but do not any longer. I switched to portmaster.

You might look at portmaster -e as it uninstalls ports and their dependencies but keeps those required by other ports.

YES! Why didn't I remember that!!!??? That looks like it might be exactly what I'm looking for, and all with one tool

Disclaimer: portupgrade and portmaster are not part of the base OS. Therefore advocating the use of non-standard tools might "annoy" (!sic) forum moderators.

What's funny about that is I have seen that very post. When you posted just now, I thought... 'isn't this the guy who got reamed for posting about the exact same thing?!'

How bout this compromise: I won't advocate, I'll just stick to using them and if others choose to do the same, they can do what they want

I do agree that if someone was completely new to freeBSD and read a post about issuing portmaster or portinstall or portupgrade commands, they could be a little confused when they get 'command not found' or something... Other than that, I don't see the problem in referring (or even advocating, I guess) tools that are referred to in the Handbook itself. It's not like a user can't search the handbook for it, then, if they're confused!


-John

 

[phoenix]

Disclaimer: portupgrade and portmaster are not part of the base OS. Therefore advocating the use of non-standard tools might "annoy" (!sic) forum moderators.

It only annoys me when people respond with things like (complete post) "run portsdb -uU" without any context or explanation of what it does, or why to run it, or even a hint that it's part of portupgrade and not part of the standard ports tools. When people add the context and the explanation for running it, there's no problem.

It's like someone sitting on the side of the highway trying to figure out how to change a flat tire, and someone else drives by and says "use a pneumatic drill" (or whatever those things are called), without mentioning that no cars come with pneumatic drills installed, nor where to go get one, nor how to use, etc.

 

[Erratus]

It only annoys me when people respond with things like ...

Hmm, sorry for your sensations. More exposure to the same makes more resistant. BTW moderator descends from moderate.

It's like someone sitting on the side of the highway trying to figure out how to change a flat tire, and someone else drives by and says "use a pneumatic drill" (or whatever those things are called), without mentioning that no cars come with pneumatic drills installed, nor where to go get one, nor how to use, etc.

This metaphor is like fantasy sitting on Fury. It's tough to produce a sequence of appropriate words.

 

[DutchDaemon]

BTW moderator descends from moderate.

No, it descends from moderator (Latin), or moderari, if you want a verb. In English, it descends from the verb [to] moderate, not the adjective or the noun (if I understand correctly where you're trying to take this).

Anyway: moderators are just regular members expressing their opinions, just like everyone else. No need to require additional 'moderacy', I believe. A moderator is supposed to moderate, not to be (a) moderate.

Semantics aside, this is a community support forum first and foremost, not a discussion platform. Cooler heads prevail.

As you were.