Synth and pkg delete

Hi!

If I use for example (I will do soon):
Code:
pkg delete gnome3
and after that should I manually delete packages in the Synth directory, please or is the other option?
Thank you.
 
why would you bother?
Who cares if a valid but unused package is in the synth repository? It doesn't hurt anything.
At some point, it will no longer be valid and then it will be pruned as obsolete.

bottom line: you should not do anything at all.
 
BTW, I've said this before, but I (and I'm sure many, many others) greatly appreciate your quick responses to any questions about synth.
 
I disagree at the fact it doesn't hurt anything. It means you are pointlessly going to be rebuilding that package whenever there is an update to it or one of its dependancies which is going to slow down the time taken to run prepare-system or upgrade-system. I'd rather have synth only rebuilding packages which I actually have installed. If you actually run a repo server for many different boxes on your network then it makes sense to keep the packages there, but if you're only using it for the local box then it's extra work for no reason.
 
I disagree at the fact it doesn't hurt anything. It means you are pointlessly going to be rebuilding that package whenever there is an update to it or one of its dependancies which is going to slow down the time taken to run prepare-system or upgrade-system.

I'm sure marino@ will quickly correct me if I'm wrong, but my (admittedly limited) observation is that Synth only builds new versions of those packages that are installed on the system. If a package is in the repository, but not installed on the system, and a new version is available in the ports tree, Synth will remove the out-of-date package from the repository without building the new version. synth prepare-system and synth upgrade-system look at what is installed to determine what to build, while synth build and synth just-build only build those ports that are explicitly fed to it by the user.
 
I disagree at the fact it doesn't hurt anything. It means you are pointlessly going to be rebuilding that package whenever there is an update to it or one of its dependancies which is going to slow down the time taken to run prepare-system or upgrade-system..

Quite false.
 
... my (admittedly limited) observation is that Synth only builds new versions of those packages that are installed on the system. If a package is in the repository, but not installed on the system, and a new version is available in the ports tree, Synth will remove the out-of-date package from the repository without building the new version.

ding! ding! ding! we have a winner!

edit: to clarify, that's only true if synth prepare-system or synth upgrade-system command is issued. Anyone can pass individual ports and ports lists and build whatever they want of course.
 
This is different compared to poudriere where the set of wanted ports is either the whole ports tree or a list of ports given on the command line or a text file. It never considers the set of installed packages on the system because that's outside of its "scope" and is up to the user to decide what he/she wants to install from the repo.
 
The only impacts to having unused packages in the repository are:
  • it takes a negligible amount of disk space
  • It adds a (likely) negligible amount of time during a repository digest/metadata/catalog construction step
Both impacts are temporary if the package's port comes off the build list (the build list either being manually fed to synth or queries to pkg(8) via the convenience commands) because the package will eventually be pruned for being obsolete.
 
This is different compared to poudriere where the set of wanted ports is either the whole ports tree or a list of ports given on the command line or a text file. It never considers the set of installed packages on the system because that's outside of its "scope" and is up to the user to decide what he/she wants to install from the repo.
But realize this is a common operating mode for Synth too, and the main mode for people building repositories for multiple machines.
Having the port list come from a pkg(8) query of the localhost is just a quick way to get the port build list. (and optional)
 
So to tie the last few posts together: the primary difference is that ports-mgmt/poudriere is intended to maintain a consistent and reliable repository for broad distribution. Both tools are great, but Poudriere is designed to operate on a scale and with a degree of reliability ports-mgmt/synth is not. Not to say that Synth is unreliable---it's worked very well for me for the last month or so---but Poudriere will aggressively rebuild packages any time there's a significant change to the ports tree ecosystem, even when it seems unnecessary, ensuring that the repository can be relied upon by many users running different system configurations with varying expectations of stability. This works quite well, but is arguably overkill with just a single system, or when several systems are close enough to identical that Poudriere's precautions aren't all that beneficial.

Synth seems to take more of a "one (type of) system, one repository" approach, and can be used to either maintain ports on a single system or maintain multiple repositories for individualized builds. It won't go out of its way to rebuild things unless the user asks for it, and separates the build and install processes while still making it possible to use them in tandem.
 
...-but Poudriere will aggressively rebuild packages any time there's a significant change to the ports tree ecosystem, even when it seems unnecessary, ensuring that the repository can be relied upon by many users running different system configurations with varying expectations of stability. [Synth] won't go out of its way to rebuild things unless the user asks for it, and separates the build and install processes while still making it possible to use them in tandem.

To the best of my knowledge, Synth and poudriere behave identically wrt to deciding to rebuild a given port. They are equally aggressive.
Synth is less robust than poudriere due to poudriere's use of true jails.
Synth has a watchdog function that is disabled right now, but once it uses a true process reaper (better than process groups) I'll re-enable it and that will increase the robustness. Ideally Synth can be as effective as building the entire tree as poudriere is. For now, poudriere is better at that job.
 
Oooooh. OK I apologise then. I misunderstood how synth dealt with that situation. If it just deletes it from the repo if an updated version appears in the ports tree and it's no longer installed any longer then that works for me. Thanks for the explanation.

When people have mentioned that it will be deleted "when the package becomes obsolete" I have taken that to mean if the entire port was deleted or moved. Which very rarely if ever happens. I see now exactly what you mean by that.
 
Oooooh. OK I apologise then. I misunderstood how synth dealt with that situation. If it just deletes it from the repo if an updated version appears in the ports tree and it's no longer installed any longer then that works for me.

Pedantically, that's not quite correct.
The criterion is not if it's installed in the system or not. The only thing that matters if if the package passes it's validity checks prior to rebuilding the repository.

For example, let's say editors/joe was updated in the ports tree.
If you "prepare-system", it will be rebuilt and the new package will pass validity checks, everything works as you indicated above.
but let's think about an alternative scenario.
Rather than using the synth prepare-system command, you first issue synth install editors/nano command. The install command rebuilds the repository as one of its steps, and during that rebuild, the old joe package will be seen as invalid and removed. The repository will be rebuilt without any joe package. It's even more dramatic when a library is removed and then everything that depends on that library gets removed as well.

This dynamic can surprise users and I'm not quite sure what to do about it.
One approach is to change the install command to NOT rebuild the repository, but just issue pkg add <path/to/repo>/<package name>. However, that might confuse pkg(8) because the installed s/w would be at a higher version than the repository digests/catalogs. Another approach might be to skip the WHOLE DIRECTORY validation step for the install command's repo rebuilding, and only do it for explicit synth rebuild-repository, synth prepare-system, and synth upgrade-system commands. The last suggestion might be the best all-around modification.
 
Back
Top