pkg autoremove: totally unreliable

[ASX]

As for mixing ports and packages, you have this thread : Thread 51531

Ah, I see you are referring to use of the unreliable portmaster and portupgrade.

Actually I'm using Synth exclusively, building from port using synth prepare-system, followed by pkg upgrade -r Synth. Unsure if that qualify as installing from ports.

 

[kpa]

Ah, I see you are referring to use of the unreliable portmaster and portupgrade.

Actually I'm using Synth exclusively, building from port using synth prepare-system, followed by pkg upgrade -r Synth. Unsure if that qualify as installing from ports.

It does certainly but with a little twist. You're building from ports but you're using an extra step of creating a binary repository out of the built ports and using that repository with ports-mgmt/pkg. If you build and install ports directly with make install you don't get a package file but the results of the build are copied from the port staging directory as if the staging directory was the result of an extracted package file.

 

[ASX]

I posted just after you and your post was not visible to me at that time. For www/firefox, there is only www/firefox-i18n. For mail/thunderbird, there are mail/thunderbird-dictionaries and mail/thunderbird-i18n. Otherwise, I have no clue why those packages have been set to automaticaly installed in your case.

Thanks, I can confirm both the i18n packages were installed before and later removed, at the same time I'm also sure firefox and thunderbird were been installed before and separately from the corresponding i18n packages.

Then, to be fair, since these two packages were set as automatically installed, then pkg autoremove worked as expected and the problem lies somewhere else. If pkg autoremove wanted to remove packages that were set as non-automatically installed, then it would be proven to be unreliable.

I agree, as I wrote before pkg autoremove itself seems to work as designed, not so sure about the pkg flags management.

Right now pkg autoremove has "nothing to do" on my system, I will monitor my install for the time being in relation to pkg autoremove..

 

[hukadan]

Ah, I see you are referring to use of the unreliable portmaster and portupgrade.

IMHO, the problem with mixing port and packages is not much about the tool you use. It is more about the fact that you install packages build from different version of the port tree (let alone different options). Much better description than mine have been made by others on this forum concerning this problem.

 

[kpa]

IMHO, the problem with mixing port and packages is not much about the tool you use. It is more about the fact that you install packages build from different version of the port tree (let alone different options). Much better description than mine have been made by others on this forum concerning this problem.

Refer to the first chapter of my Poudriere HOWTO, it's a quite complete summary of everything wrong with the plain ports(7) system and the frontend tools like ports-mgmt/portmaster that don't separate the port building from the host.

Thread 38859

 

[ASX]

IMHO, the problem with mixing port and packages is not much about the tool you use. It is more about the fact that you install packages build from different version of the port tree (let alone different options). Much better description than mine have been made by others on this forum concerning this problem.

Well, I agree with you, and that's why I switched to use ports-mgmt/synth exclusively, which help to prevent many of these mismatches, I continue to see how portupgrade and portmaster are unreliable, yet they are still the officially suggested tools to build from ports, unfortunately.

 

[ANOKNUSA]

I am really surprised that none of the documentation notes the -leaf option.

It's an alias. Check out /usr/local/etc/pkg.conf and pkg.con(5) for some ideas on writing your own. I switched min up to query -e '%a = 0' %o | sort -d, which makes it list the port origins alphabetically by port name, rather than by package name and version. I remember seeing kpa share something similar not that long ago, but can't remember the difference.

 

[kpa]

It's an alias. Check out /usr/local/etc/pkg.conf and pkg.con(5) for some ideas on writing your own. I switched min up to query -e '%a = 0' %o | sort -d, which makes it list the port origins alphabetically by port name, rather than by package name and version. I remember seeing kpa share something similar not that long ago, but can't remember the difference.

https://forums.freebsd.org/threads/58889/#post-336933

Your version just checks for the automatic flag (which is the wrong indicator if you happen to delete leaf metaports), mine checks if the installed package is required by any other packages.

 

[Hanky-panky]

Well, I agree with you, and that's why I switched to use ports-mgmt/synth exclusively, which help to prevent many of these mismatches, I continue to see how portupgrade and portmaster are unreliable, yet they are still the officially suggested tools to build from ports, unfortunately.

I don't agree at all. Experience proved portmaster and building/upgrande source and kernel from scratch are the only serious way to maintain a FreeBSD machine. Pkg and freebsd-update proved IMHO to be contradictory and unreliable especially on deep customize Os installs.

Sorry for no formatting. I am on my beloved iPAD and very pressed.

 

[kpa]

Well, I agree with you, and that's why I switched to use ports-mgmt/synth exclusively, which help to prevent many of these mismatches, I continue to see how portupgrade and portmaster are unreliable, yet they are still the officially suggested tools to build from ports, unfortunately.

Until we got Synth there was no way you could recommend anything else to an average user. Poudriere for example requires setting up jails and is sometimes not so user friendly if you're not completely "in the know" of how certain things work. In my opinion Synth should be the default recommendation for ports building now that we have it because it's reliable, quite user friendly and removes much of the headaches involved in ports building that you constantly run across using the ports(7) system and the less sophisticated tools.

 

[Hanky-panky]

Until we got Synth there was no way you could recommend anything else to an average user. Poudriere for example requires setting up jails and is sometimes not so user friendly if you're not completely "in the know" of how certain things work. In my opinion Synth should be the default recommendation for ports building now that we have it because it's reliable, quite user friendly and removes much of the headaches involved in ports building that you constantly run across using the ports(7) system and the less sophisticated tools.

Synth is just another layer of complexity. Portmaster just works.

 

[marino]

Hanky-panky@: you're just wrong. Portmaster does not "just work" and only people that don't know any better consider it for "serious use" and superior to poudriere and synth.
Basically, if you are convinced portmaster is superior (in addition to having zero actual experience with poudriere and synth) then you're just a person that refuses to be educated and really the thread should end.

 

[marino]

I didn't installed Gnome meta-port becouse I do personalize my system and I just install needed ports, then it is not a good reason for a serious package manager to call my perfectly customnized Gnome 3 as leftovers.

And what about Clang? It works perfectly fine and that kinky package manager call it a leftover, I need it to build some stuff, and Samba (?!?!?!?) how can it call it leftover if it is constantly used and in charge of file sharing on that machine?

Come on, pkg, in this case of autoremove, it is totally unreliable.

well, this response pretty much confirms it. He's been told the problem was user error, yet he thinks pkg(8) magically has to know that the dependency clang should be updated to primary package because "he uses it" and still thinks pkg(8) is unreliable. When people blame everyone and everything before considering themselves at fault, there's no point in continuing. Let HP believe what he wants and let him solve his own issues.

 

[kpa]

I've said what I had to say. If you're still convinced that you know better I challenge you to refute my points about what is wrong with the ports system in my Poudriere HOWTO. Everything you're complaining about is directly related to those faults and the message we've been trying to drive home is that tools like portmaster do not offer proper solutions to those faults, tools like Synth and Poudriere when used properly do.

 

[Hanky-panky]

I've said what I had to say. If you're still convinced that you know better I challenge you to refute my points about what is wrong with the ports system in my Poudriere HOWTO. Everything you're complaining about is directly related to those faults and the message we've been trying to drive home is that tools like portmaster do not offer proper solutions to those faults, tools like Synth and Poudriere when used properly do.

Sorry KPA but what I complained about is related to a pkg command, exactly the unreliable autoremove. Nothing to do with portmaster. And in this case it not IMHO, it is a fact.

 

[Hanky-panky]

Hanky-panky@: you're just wrong. Portmaster does not "just work" and only people that don't know any better consider it for "serious use" and superior to poudriere and synth.

Ok so you call FreeBSD foundation 'people that don't know any better' considering that portmaster is the official choice for managing ports.

 

[marino]

Ok so you call FreeBSD foundation 'people that don't know any better' considering that portmaster is the official choice for managing ports.

That's a false statement. Portmaster is not recommended. All implied preference for it is supposed to be removed from documentation.
Please provide a link showing this "official choice" so we can get it changed (or at least prove your assertion which I am strongly calling wrong)

 

[kpa]

The handbook is user contributed mostly, just look at the credits in it. The FreeBSD Foundation pretty much only provides the facilities, the web servers etc. to host the user documentation.

 

[roddierod]

Are you aware on any package/port that could pull in firefox or thunderbird as dependencies ?

www/conkeror will pull in firefox as a dependency if you choose to use it as the rendering engine.

 

[ASX]

www/conkeror will pull in firefox as a dependency if you choose to use it as the rendering engine.

Thanks, as I answered before in post #28, I had firefox-i18n installed and later removed. (same for thunderbird).
As far as I can remember I have installed firefox alone originally, with default settings, however firefox-i18n removal is a strong hint I could have done it the wrong way,

 

[Hanky-panky]

That's a false statement. Portmaster is not recommended. All implied preference for it is supposed to be removed from documentation.
Please provide a link showing this "official choice" so we can get it changed (or at least prove your assertion which I am strongly calling wrong)

Just look at official /usr/ports/UPDATING and you will see they always refer to portmaster and portupgrade, usually in this order, when they speak about ports management. Shouldn't this say something?

 

[marino]

Yes, it says users of those tools are forced to do extra steps that repository users don't have to do.
Or did you not notice there are no instructions for poudriere/synth + pkg(8) users?

 

[Hanky-panky]

Yes, it says users of those tools are forced to do extra steps that repository users don't have to do.
Or did you not notice there are no instructions for poudriere/synth + pkg(8) users?

Yes, it is becouse those two packages are simply unofficial contributions (simple ports like thousands of others) they don't need to cover. As I said before, just another layer adding complexity to the whole package management. they just consider pkg for binary users and portmaster/portupgrade for building from source. That's all.

 

[marino]

"That's all" wrong.
You're just wrong. It's not a subjective thing.
Poudriere is as official as it gets. All binary packages distributed by FreeBSD are built by it.
All you've proven is that you have lots of opinions and apparently none of them based on any kind of fact.
That's all.

 

[kpa]

Yes, it is becouse those two packages are simply unofficial contributions (simple ports like thousands of others) they don't need to cover. As I said before, just another layer adding complexity to the whole package management. they just consider pkg for binary users and portmaster/portupgrade for building from source. That's all.

Wrong answer, they are no less "official" than the older portmaster and portuprade tools. The real reason is that you never need apply those hacky workarounds when using pkg-upgrade(8) with a binary repository such as the official repositories or one built by yourself. pkg(8) is able to use its rather clever conflict solver when used with a binary repo to figure out which packages have to replaced to avoid conflicts when doing updates, this is not possible at all with portmaster that still installs only one port at a time.