- As a result, the de facto current situation is that the primary ports maintainers use the new way of maintaining and developing the ports infrastructure (based exclusively on poudriere), but that modern reality is not reflected in the user-facing documentation. The documentation could lull you into thinking the traditional make-based targets all work just like they used to, but they are actually subtly broken in various ways.
I don't quite agree with that assement and I think you may be in the process of blaming a messenger here.
Thing is... I have 0 interest in Poudriere and never really liked the idea of using it. In fact I'm quite a vivid Portmaster user. Basically I rely on Portmaster in combination with "Portmaster Assist" which is a set of shell scripts I build to make my life a bit easier. But other than that I fully rely on everything that's mentioned in
ports(7) and even when dealing with ports that barely had any updates I still don't run into major issues.
In fact... take the issue with the circular dependencies between
devel/glib20 and
devel/gobject-introspection... a classic case I think because this can cause you some issues, whereas
20250402 of
/usr/ports/UPDATING clearly mentions that this issue will mostly affect people who don't use Poudriere.
Now... that may be true but it doesn't change the fact that even without Poudriere you can still (somewhat) easily fix the issue, courtesy of using FLAVORS. A feature that has been part of the ports collection for quite some time.
Also... this thread was originally about Autobahn and apart from that weird bug in the
Makefile I had no problems with building it. All while using the classic method(s) of
make build.
- The specific one I ran into was "make config-conditional" (which portmaster also relies upon), but who knows what else is on shaky ground?
But this wasn't even a real issue, the actual problem was a fault in the
Makefile. This build target never misbehaved either, it did exactly what it was supposed to do.
And I base that conclusion on the fact that I have no problems with building Autobahn as soon as I get rid of that weird definition I mentioned earlier. Note: not using any 'fancy' build jails, directly build using a production system.
While I did get that clear message (which you linked) that "make config-conditional" is not valid for flavored ports,
That doesn't look like a correct assesment either.
If you want to talk flavors... how about the new requirements for
devel/glib20 as mentioned above?
Code:
root@bsd:/usr/ports/devel/glib20 # pkg info -ox glib
dbus-glib-0.114 devel/dbus-glib
glib-2.84.1_2,2 devel/glib20
root@bsd:/usr/ports/devel/glib20 # grep FLAVORS Makefile
FLAVORS= default bootstrap
FLAVOR?= ${FLAVORS:[1]}
FLAVORS_SUB= yes
root@bsd:/usr/ports/devel/glib20 # make config-conditional
root@bsd:/usr/ports/devel/glib20 #
You see? Behaves
exactly as one would expect.
I never did get a similarly-clear indication of just what exactly would *break* if that seemingly-wrong OPTIONS_FILE=xxx line were to be removed. Of course, it fixes a problem for me and for anyone else using a workflow like mine, but presumably it would break something else, using a more official workflow?
It wouldn't. Because it's not common behavior, not even when using FLAVORS, to define a dedicated options file:
Code:
root@bsd:/usr/ports/devel/glib20 # grep OPTIONS Makefile
OPTIONS_DEFINE= DOCS FAM_ALTBACKEND MANPAGES NLS TEST
OPTIONS_DEFAULT= MANPAGES
OPTIONS_SUB= yes
OPTIONS_DEFINE=
You can also read as much in the
Porters handbook. You'll notice that even the sample
Makefile does not bother with specifically defining the options file. Simply because there's no need to.
I really wish I knew what that something else was. I feel like that would have been a simple end of the issue — "sorry, we can't do X because it would break Y in the official builds." But nobody ever gave me that sort of concrete answer. There were only vague and general statements about how this (documented) target should not be called directly, how things are done differently nowadays, how filing this sort of bug is invalid, etc. etc.
Well, they are right about the build target.
And with all due respect... but if you point out problems with a port, only to base your conclusion on a somewhat flawed expectation from a build target that hardly anyone uses (definitely not interactively) then I can understand their initial hesitations.
One thing to keep in mind... port maintainers are volunteers, and not everyone has the same level of expertise or understanding about the port mechanics. Don't read between the lines here... I
don't mean this in a negative way. Just stating general facts.
For example... at the time of writing I'm busy doing a self-study (refreshment) on Kerberos ("GSSAPI"), and sure enough.. not everyone is fully aware of how this works. If you check PostgreSQL then you'll notice that the port provides support for
security/krb5 while claiming that this is providing GSSAPI support for the base system. Which is actually not true, because the FreeBSD base system relies on Heimdal (
security/heimdal), not MIT. And you can't really mix those up, it's not reliable.. An easy to spot fact if you're more familiar with the Kerberos implementation(s), but if not then it's easy to mix up these facts.
For the record... I checked that PR again and well, I do
not agree with the conclusion. From my POV
www/py-autobahn is
definitely broken right now because it doesn't retain its build options when using
# make config.
And well... this conclusion is very easy to argument.. just look at
/var/db/ports. You will notice that Autobahn is the
only port that doesn't use a mere
options file. Not even Python renames this. Which is the main reason why running
# make config a second time doesn't restore those build options.
That's courtesy of
/usr/ports/Mk/bsd.options.mk, because guess what?
Code:
OPTIONS_FILE?= ${PORT_DBDIR}/${OPTIONS_NAME}/options
Because
that ^ is the default, and this file ("
options") gets loaded as soon as you run
# make config a second time. If the file isn't there then the system falls back to defaults. Renaming the options file in the Makefile... that's a rookie mistake.
I can understand your frustration, I really do, but at the same time you also made the whole PR quite messy. Especially because you kept putting emphasis on
config-conditional several times, even though that has
nothing to do with any of this.
Instead of the build target it would probably helped you out better had you
pointing pointed out the above file
bsd.options.mk, because that clearly showcases the default and common standard being
options.
(edit)
Just so we're clear...
Chapter 5.14 of the Porters handbook:
Porters Handbook said:
OPTIONS_* give the user installing the port a dialog showing the available options, and then saves those options to ${PORT_DBDIR}/${OPTIONS_NAME}/options. The next time the port is built, the options are reused.
Now why do you think the Handbook specifically describes the full path to the
options file? Because you're not supposed to change this. This also gets somewhat reflected on here:
Order of Variables in FreeBSD Port Makefiles
docs.freebsd.org
(edit
2)
So I figured I'd "do" something:
Code:
peter@bsd:/usr/ports $ find ./ -type f -name Makefile -exec grep OPTIONS_FILE {} \; -print
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options
./net-p2p/transmission-components/Makefile
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options
./devel/git/Makefile
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options
./mail/postfix/Makefile
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options
./mail/postfix-current/Makefile
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options
./www/py-autobahn/Makefile
peter@bsd:/usr/ports $
Out of
all the thousands of ports... only
5 of them use this same mechanic. Where
only Autobahn refuses to reload the saved options (I just tested this).
Well... I
also stand corrected (!) because it's not necessarily the mentioned line itself that breaks this port. It's the broken sequence of options. As per the Porters handbook (link above): the sequence in which you define the options in the Makefile is
very important.
devel/git Makefile:
Code:
.if ${SUBPORT} == core
FLAVORS= default lite tiny
...SNIP....
. if !empty(FLAVOR) && ${FLAVOR:U} != default
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options
. endif
mail/postfix Makefile:
Code:
FLAVORS= default ldap mongo mysql pgsql sasl sqlite
....SNIP....
.if !empty(FLAVOR) && ${FLAVOR:U} != default
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options
.endif
www/py-autobahn Makefile:
Code:
peter@bsd:/usr/ports/www/py-autobahn $ grep -e ^FLAVOR Makefile | wc -l
0
peter@bsd:/usr/ports/www/py-autobahn $ grep -e ^FLAVOR ../../mail/postfix/Makefile | wc -l
1
peter@bsd:/usr/ports/www/py-autobahn $
See what I'm getting at?
Autobahn uses a
${FLAVOR} definition, yet it
never defined one!
Every other port that (re)defines the options file using its FLAVOR
also makes sure that this is actually defined, one way or another. Autobahm ignores this entirely.
So... the port is
definitely broken, but
not necessarily because of that line, yet rather because of the use of an undefined (!) FLAVOR.
(edit 3 (final edit!)) =>
Flavors are a way to have multiple variations of a port
docs.freebsd.org
Notice how the handbook also mentions that in order to use Flavors... you need to define them.
