Best way to manage ports?

Erichans said:
When running -CURRENT, you do need to do that.
Click to expand...

As far as I can see, there actually are packages for 14, which is -CURRENT afaik (only the latest branch though):
My example Chromium e.g. seems to have a package for 14:

FreshPorts -- www/chromium: Google web browser based on WebKit

Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web. The Chromium website contains design documents, architecture overviews, testing information, and more to help you learn to build and work with the Chromium...
www.freshports.org www.freshports.org
 
TheDantee said:
SirDice DutchDaemon ok so after building the system I am running into common place issues when removing certain options. On Gentoo when I change an option in my make.conf the package manager portage finds all the affected packages with that option and allows me to change it and of course there is a custom package.use file so set specific different options for different packages that may differ from the global. On Poudriere can I do something similar where I change the options in make.conf is there a command I can run where it will update the options for those affected packages or at least see the config again for only those packages without manually deleting the config?

Also when a package fails to build in Poudriere it just says failed build is there like a log somewhere to find out why?

Lastly Is there a way to setup certain variables to fix said issues with compiling with something similar to this or do I need an entire separate poudriere jail for just one or two packages that may act up? - https://wiki.gentoo.org/wiki//etc/portage/package.env

Thanks!


For what its worth I can install binaries on -CURRENT just fine and they work fine.
Click to expand...
Don't try to mix in Gentoo documentation when setting up Poudriere... that invites trouble and confusion.

FreeBSD also has a make.conf. But it works differently from what you describe. It sets global make rules, like "Always turn on the DOCS flag, even if it's off by default". make config in the port's directory will reflect that - just because the make part of that command will invoke a re-reading of that global make.conf file. Nope, it won't go off looking for other ports.

Yeah, you have to be careful of dependencies when you turn options on.

Frankly, I'd suggest that you lay off Poudriere for a while, until you get comfortable with the ports.

And don't go mixing ports and packages - there's a truckload of details to pay attention to, and a mismatch invites trouble. 😮‍💨
 
astyle said:
Don't try to mix in Gentoo documentation when setting up Poudriere... that invites trouble and confusion.
Click to expand...
For sure I am just trying to see whats similar and what's different to better understand.
astyle said:
FreeBSD also has a make.conf. But it works differently from what you describe. It sets global make rules, like "Always turn on the DOCS flag, even if it's off by default". make config in the port's directory will reflect that - just because the make part of that command will invoke a re-reading of that global make.conf file. Nope, it won't go off looking for other ports.
Click to expand...
Yes we have that on Gentoo as well however some packages need a flag where say a majority may not so in the global I would set it to disabled and enable it only for what needs it.
astyle said:
Frankly, I'd suggest that you lay off Poudriere for a while, until you get comfortable with the ports.
Click to expand...
What else should I focus on learning?
astyle said:
And don't go mixing ports and packages - there's a truckload of details to pay attention to, and a mismatch invites trouble. 😮‍💨
Click to expand...
Interesting...
 
TheDantee said:
Yes we have that on Gentoo as well however some packages need a flag where say a majority may not so in the global I would set it to disabled and enable it only for what needs it.
Click to expand...
I use ports because I often disagree with the defaults provided by pkg. In the process, I recompiled my ports many times. In the process, I learned that the ports framework actually remembers the flags I set. The poudriere(8) manpage says it's in /var/db/ports/ directory. If only a few packages need a flag, I find 'em by hand, cd into port directory, run make config, and adjust my options there. This is faster and less error prone than trying to edit a global file and then figuring out how to filter from that correctly.
TheDantee said:
What else should I focus on learning?
Click to expand...
I'd suggest focusing on the ports, setting options, and learning how to troubleshoot when a compilation messes up. I switched to FreeBSD when I discovered that it runs KDE just fine. After that, I learned the ports system, and how to adjust the makefile options via make config. Took me awhile, I sometimes created circular dependencies, and had to troubleshoot my way out of them. But now I can compile my way into a functional KDE desktop. I took notes, and was able to figure out what comes first, second, etc. Order of steps matters. And only after I did all that, I started thinking that Poudriere might be of benefit to me...
TheDantee said:
Interesting...
Click to expand...
See this thread for an interesting discussion on the consequences of mixing ports and packages: Thread vlc-and-cannot-mix-incompatible-qt-library.87866/
 
astyle said:
I use ports because I often disagree with the defaults provided by pkg. In the process, I recompiled my ports many times. In the process, I learned that the ports framework actually remembers the flags I set. The poudriere(8) manpage says it's in /var/db/ports/ directory. If only a few packages need a flag, I find 'em by hand, cd into port directory, run make config, and adjust my options there. This is faster and less error prone than trying to edit a global file and then figuring out how to filter from that correctly.
Click to expand...
I do the same but for most things I actually want it disabled globally. I don't like having multiple sound servers for example or a need for icu or nls. I have figured out the configs in Poudriere already and have cleared them a few times already Gentoo is much ahead on the curve on this IMO, ports should take notes. I saw in the read me section of the forums posts like why isn't FreeBSD more like ... where you can't compare it to Linux and stuff I don't like this idea the discussion should be open some things are simply better or maybe can be recreated better like bhyve vs kvm which is off topic. For my use case I understand Gentoo's package management setup and have been compiling alot of things manually for some time and just trying to figure out the similarities as after all its all basically the same at the end of the day some option flags and make the package.
astyle said:
I'd suggest focusing on the ports, setting options, and learning how to troubleshoot when a compilation messes up.
Click to expand...
Yes IK these things from Gentoo already troubleshoot would be my next step as I'm getting errors, as expected though no complaints here nothing I probably can't fix.
astyle said:
I took notes, and was able to figure out what comes first, second, etc. Order of steps matters. And only after I did all that, I started thinking that Poudriere might be of benefit to me...
Click to expand...
Woah woah woah hold on... So Poudriere doesn't automatically know package X relies on package Y and will build it first? It has to... I would expect way more errors than I'm getting and that would horrible design. I still prefer Portage over Poudriere at this time however I am forcing myself to live outside of Linux and really try to stick with it I don't like many of the design choices the kernel is headed and I dislike GNU as well as systemd reliance even on an init system like s6 or runit I needed specific packages to make other packages that rely on systemd happy so yeah I don't have it but I have to use workarounds anyways just to avoid it... in other words horrible design.
astyle said:
See this thread for an interesting discussion on the consequences of mixing ports and packages: Thread vlc-and-cannot-mix-incompatible-qt-library.87866/
Click to expand...
Ah issues like these yes I understand I've seen this on Gentoo before. On Gentoo you need to build everything from source if you use glibc instead of musl you can get some binaries for larger packages through the main package manager portage as well this is why I mentioned pkg should support both earlier. Not trying to come off as a snob or anything just generally curious how others are building packages, the reason I mentioned Gentoo is because it's a main focus in that OS and offered me alot of experience with building and errors I only bring up suggestions as constructive criticism not even Gentoo is perfect ;)
 
TheDantee said:
Woah woah woah hold on... So Poudriere doesn't automatically know package X relies on package Y and will build it first? It has to... I would expect way more errors than I'm getting and that would horrible design. I still prefer Portage over Poudriere at this time however I am forcing myself to live outside of Linux and really try to stick with it I don't like many of the design choices the kernel is headed and I dislike GNU as well as systemd reliance even on an init system like s6 or runit I needed specific packages to make other packages that rely on systemd happy so yeah I don't have it but I have to use workarounds anyways just to avoid it... in other words horrible design.
Click to expand...
I think you got it wrong about Poudriere - Poudriere does not resolve dependencies. It runs those same make commands that you do in /usr/ports. The make command, run within the ports system, is what actually resolves dependencies. What Poudriere does is set up a jail and some directories, but after that, it's simply scripting those same make commands in sequence. This is why I suggested that you first get comfortable in the ports system, and get used to the outputs. Once you know enough to start making a repeatable list of chores that it takes to get to having your packages properly compiled, that's when you know you're ready for Poudriere. It's all about automation of those chores.

FWIW, Gentoo's Portage was inspired by FreeBSD's ports. And being able to troubleshoot your way out of self-created dependency hell serves you equally well on both the original (FreeBSD) and derivative (Gentoo).

IDK if Portage also has to act as a package manager and enforce/resolve dependencies. Poudriere just leaves those chores to pkg(8) and make(1), respectively.

Oh, and if you read the poudriere manpage, you'll discover that Poudriere doesn't care what options the ports have. If make is happy, that's all Poudriere needs... in fact, you can have several sets of those options, if you like. :p
 
The make.conf is important when you use eg poudriere.

You can get out a dependency hell for 90% by specifying default versions in make.conf
Eg
Code: 
DEFAULT_VERSIONS+= mysql=10.6m
DEFAULT_VERSIONS+= ssl=openssl
For the rest 10% you can turn of options for packages in make.conf in order to avoid conflicts,
Code: 
OPTIONS_UNSET+=GSSAPI_BASE
OPTIONS_UNSET+=GSSAPI_HEIMDAL
OPTIONS_UNSET+=GSSAPI_MIT
OPTIONS_UNSET+=IMAGEMAGICK
OPTIONS_UNSET+=IMAGEMAGICK6
OPTIONS_UNSET+=IMAGEMAGICK7

My current PC has 2800 packages compiled from source & installed without any conflict.
 
Alain De Vos said:
My current PC has 2800 packages compiled from source & installed without any conflict.
Click to expand...
That's an insane amount of packages! I play with options to lower the dependencies to have less packages installed on my system making it as light as possible while performing the functions I need.
 
I always pick GSSAPI_BASE, DOCS=yes and openssl over alternatives, so I guess in my case, those could be set in /etc/make.conf... 😅 I do have to watch out, though: In one case, devel/doxygen did not compile for me, and I had to make sure just a few (not all) of my subsequent selections excluded DOCS=yes, because on those specific ports, that option invoked doxygen without making that terribly clear. Well, once the options are lined up without Poudriere, then I know that they can be fed to Poudriere.
 
When I run "poudriere ports -u -p local -f pkglist" it updates the packages and then I rerun bulk to build the packages it not only deletes the packages that need updated but deletes packages that depend on those packages despite already being built? This seems like a waste of time to rebuild something for a minor library change constantly is there a better way to handle this?
 
TheDantee said:
When I run "poudriere ports -u -p local -f pkglist" it updates the packages
Click to expand...
No. poudriere ports -u -p local will update a ports tree named 'local'. The added -f pkglist doesn't make sense and will either cause an error or is simply ignored. Note that this does NOT update packages. It updates the ports tree.
TheDantee said:
then I rerun bulk to build the packages it not only deletes the packages that need updated but deletes packages that depend on those packages despite already being built?
Click to expand...
Yes, their dependency changed, so they need to be rebuild in order for the dependency chain to stay correct.
TheDantee said:
This seems like a waste of time to rebuild something for a minor library change constantly is there a better way to handle this?
Click to expand...
Technically correct but it's done to make sure all dependencies properly line up. The build system cannot discern if this is a minor (non-breaking) change or not. And sometimes "minor" library changes break things that depend on them. It errs on the cautious side and just rebuilds everything that has a dependency on it.
 
Oh, -f is a valid option for poudriere-ports(8) but this selects the filesystem to use, it's not a list of packages. The option only makes sense in combination with -c.

Code: 
     -f filesystem  The name of the filesystem to create for the ports tree.
                    If set to “none” then do not create a filesystem.
                    Defaults to “poudriere/ports/default”.
 
cracauer@ said:
Our of curiosity, do you do this mostly to turn on additional functionality / more dependencies, or something else?
Click to expand...
Yeah, mostly to turn on additional functionality. I want the full power of FFMPEG and VLC, for example. Having the option (to have the full-powered stuff) easily available to me via the ports system, and then Poudriere to automate the chores to make that happen - that's part of FreeBSD's appeal to me.
 
SirDice said:
No. poudriere ports -u -p local will update a ports tree named 'local'. The added -f pkglist doesn't make sense and will either cause an error or is simply ignored. Note that this does NOT update packages. It updates the ports tree.
Click to expand...
That's what I meant bad communication on my part.
SirDice said:
Oh, -f is a valid option for poudriere-ports(8) but this selects the filesystem to use, it's not a list of packages. The option only makes sense in combination with -c.

Code: 
     -f filesystem  The name of the filesystem to create for the ports tree.
                    If set to “none” then do not create a filesystem.
                    Defaults to “poudriere/ports/default”.
Click to expand...
Gotcha thanks!

If the options change like something new is added should I rerun options every time I update and with poudriere automatically show me the config for the packages where new options were added?
 
TheDantee said:
If the options change like something new is added should I rerun options every time I update and with poudriere automatically show me the config for the packages where new options were added?
Click to expand...
Yes and yes. New options will have a '+' indicated next to them, making them easy to spot. That said, I've used poudriere-options(8) for quite a long time, but options changing are a royal pain. You're better off setting those options through a make.conf file, like I showed in post #6. That's much easier to deal with. And it is clearer which options you've set (or unset).
 
SirDice said:
Yes and yes. New options will have a '+' indicated next to them, making them easy to spot. That said, I've used poudriere-options(8) for quite a long time, but options changing are a royal pain. You're better off setting those options through a make.conf file, like I showed in post #6. That's much easier to deal with. And it is clearer which options you've set (or unset).
Click to expand...
Yes I have the main ones set in the make.conf already but sometimes like recently KeepassXC added an option for Xorg in an update not long ago just would be nice to know those changes if they are not auto set from make.conf
 
TheDantee said:
I need to get used to reading manpages... I'm so used to reading wiki pages on the specific task.
Click to expand...
Yes, opening a browser to search how to fix something on your computer is a culture that usually comes from windows (because it doesn't have man pages) and survives in linux (because linux man pages are usually outdated and/or too simplistic).

BSD's man pages are very good and should be the first place to search for something (OpenBSD guys take this very seriously).
 
BobSlacker said:
Yes, opening a browser to search how to fix something on your computer is a culture that usually comes from windows (because it doesn't have man pages) and survives in linux (because linux man pages are usually outdated and/or too simplistic).

BSD's man pages are very good and should be the first place to search for something (OpenBSD guys take this very seriously).
Click to expand...
For FreeBSD, at least, manpages are also available via a web-browser (if links like man(1) are any indication ;) )
 
TheDantee said:
I need to get used to reading manpages... I'm so used to reading wiki pages on the specific task.
Click to expand...
astyle said:
For FreeBSD, at least, manpages are also available via a web-browser (if links like man(1) are any indication ;) )
Click to expand...
Please be aware of the limitations when reading and referencing poudriere man pages such as poudriere-options(8)

The man page website only displays* the set of man pages from ports-mgmt/poudriere-devel
This is due to unresolved collisions of the (file)names of the man pages in the two versions:
  1. ports-mgmt/poudriere
  2. ports-mgmt/poudriere-devel
These two version are not the same, obviously. They are mutually exclusive when installed as packages; I assume that holds for creating one's own packages from ports as well. Your local man pages should reflect the installed version.

For both versions, man pages are mostly the same but not always as is reflected by the fundamental difference between a "standard" and development version.

For example, from ports-mgmt/poudriere for poudriere-options(8):
Rich (BB code): 
NAME
     poudriere options -- configure the	options	for a given port

SYNOPSIS
     poudriere [poudriere-options] options [options] -f file
     poudriere [poudriere-options] options [options] origin	[origin2 [...]]

[...]
OPTIONS
>>NO -o option <<

From ports-mgmt/poudriere-devel for poudriere-options(8):
Rich (BB code): 
NAME
     poudriere options -- configure the	options	for a given port

SYNOPSIS
     poudriere options [options] -f file
     poudriere options [options] origin	[origin2 [...]]

[...]
OPTIONS
[...]
   -o port_dbdirname
		Use the	specified directory name to write the options to.
		This name will expand to $POUDRIERE_ETC/$port_dbdirname.  This
		can be used to write options to	a different directory than
		-jpz specify.  The -jpz	flags will be used for the make.conf,
		poudriere.conf,	and ports dir.

When referencing poudriere on this forum it would therefore also be preferable to mention if one is using ports-mgmt/poudriere or ports-mgmt/poudriere-devel


There are of course the man pages at the poudriere github that do differentiate between the two versions. For example:
  1. poudriere options.8
  2. poudriere options.8 devel

___
* Compare poudriere-options for FreeBSD Ports 13.1 with the above referenced snippets.
 
Erichans oh, boy... I got lost on the differences between ports-mgmt/poudriere and ports-mgmt/poudriere-devel here... I was just happy to get the former working correctly for me, after months of effort of lining the details up, and I'm still not done (well, my project is a bit more than just running Poudriere, I'm trying to accomplish something with it, but that's another story).

Let's try to consider the audience when we post: OP said:
TheDantee said:
I need to get used to reading manpages... I'm so used to reading wiki pages on the specific task.
Click to expand...
so let's try to avoid information overload, and point to best practices instead...
 
You must log in or register to reply here.
Back
Top