Synth: Scan of * failed (port deleted), it will not be considered.

I am using synth but looks like I dont understand well the building process or how actually ports handle the deleted packages. I started to get the messages from synth:

Code:
Scan of lang/ruby21 failed (port deleted), it will not be considered.                                                                  
Scan of mail/dovecot2 failed (port deleted), it will not be considered.                                                                
Scan of mail/dovecot2-antispam-plugin failed (port deleted), it will not be considered.                                                
Scan of mail/dovecot2-pigeonhole failed (port deleted), it will not be considered.                                                     
Scan of devel/libcheck failed (port deleted), it will not be considered.                                                               
Scan of security/sshguard-pf failed (port deleted), it will not be considered.                                                         
Scan of lang/clang36 failed (port deleted), it will not be considered.                                                                 
Scan of devel/llvm36 failed (port deleted), it will not be considered.                                                                 
Scan of devel/llvm37 failed (port deleted), it will not be considered.

Can i delete those ports (and they were replaced by newer versions - for llvm i know 4x was built) or there are still some dependant applications on the system?
 
I'm not sure how Synth handles this, I know poudriere simply fails to build ports that don't exist any more. I had to edit my list of ports to build to fix that.
 
if you are using synth upgrade then probably you have packages from those deleted ports installed on your system.

In other words, you install clang36 in the past and it's still installed even though the port got deleted. If you uninstall the packages using pkg remove those notices will go away the next time you try "synth upgrade"
 
Ok, just as a feedback if someone else is expiriencing same problems, the issue is not only that some packages were obsoleted but some were also moved to different package names etc.

At the end i looked at /usr/ports/CHANGED and due to inconsistency of some ports maintainers into /usr/ports/MOVED and check the reported packages to either rename them or really remove them using pkg remove. The only one left that was left puzzling me is libexecinfo, where the entry within MOVED is saying:

Code:
devel/libexecinfo||2017-09-22|Is present in the base system of all supported releases

I understand the statement but I am worried that pkg remove will screw something.

/RANT ON

One more thing pkg autoremove is close to useless. The entries that would be removed are all packages that no port is dependent to BUT those are also utilities which were installed as stand alone, like zip etc. and would be removed if the command would be run, which is completely wrong. Looks like the installed packages database is missing entry if the pkg was installed as a dependency of another package or directly executed by user (or something else is screwed up). I dont understand why this is still such a pain in the neck in year 2017 and I see it as upmost importance to be fixed once and for all, not only the part of removing the orphaned packages but also the renaming / replacing them with new name in ports tree etc. I love freebsd, but this packages/ports system is a real problem up, the installation is more or less simple and it works great but keeping your system clean is much too complicated, and the pkg set -A 0 is a joke. I will be using it now but, this is just something that I expect to be handled by the pkg system.

The CHANGED and MOVED files are nice to have but using the text file aproach to maintain the upgrades is... omg... instead of using the script for each port that was moved or something that would be executed when such event occurs, it is textually described. I just cant find the words how wrong this is.

A normal user (or even I) shouldnt be required to know so much about the packing system to be able to keep it running, updating etc. This is something you expect to not care about, it should just work.

/RANT OFF


I am keeping the option that I dont know about something vital but since I am using the freebsd since version 8 and I was always plagued by those problems I dont think I have missed something
 
One more thing pkg autoremove is close to useless. The entries that would be removed are all packages that no port is dependent to BUT those are also utilities which were installed as stand alone, like zip etc. and would be removed if the command would be run, which is completely wrong.
This won't happen. And you can always set a package to not be removed with pkg-autoremove(8): pkg set -A 0 <somepackage>. See pkg-set(8)
 
Sure, i have installed zip and unzip packages. Why would any package depend on them? But I do depend on them :)

And i do know what you will answer, use "pkg set -A 0". :) Sure, I will but this is not something user will expect from freebsd and I bet most of users reading this have heard about it the first time. This is something that pkg install should do.
 
This is something that pkg install should do.
It actually does. But only if you initially installed a package by hand (using pkg-install(8)). It will not "automagically" change an automatic dependency to a non-automatic one just because you are using it. That's not how package systems work, any package system, on Linux or on FreeBSD. As a matter of fact FreeBSD's pkg-autoremove(8) works in exactly the same way as Debian's apt-get autoremove for example.

A pkg-autoremove(8) will remove packages only if both of the following conditions are met:
  • Said package was initially automatically installed as a dependency of another package
  • Said package doesn't have any other (installed) packages depending on it.

The reason you seem to have a hard time with pkg-autoremove(8) is mostly because you don't understand how it works and have unrealistic expectations.
 
Back
Top