HEADSUP: FLAVORS (initial version) and subpackages proposals
dewaynegeraghty at gmail.com
Tue Dec 20 08:11:43 UTC 2016
Thanks Bapt et al,
I use FreeBSD and the ports system extensively, we build everything from
source and largely customise approx 25% of the 900 packages we rely upon.
I'm more than a little concerned to have changes performed against the
ports infrastructure. As our primary sources of (whats coming) "Change"
information are the: Quarterly reports and the OS Release Notes;
after-the-fact sources are a daily review of
for OS impact; and the excellent Freshports.
So a few questions:
Could you be able to enlighten us (the readers) so we can better understand
what will be changed; or share your vision of the benefits and operational
impact for operational people that build: from source; and those that only
Is there a transition plan or schedule for the bulk of these changes to
Will the flavors/subpackages be developed separately from the existing
ports suite? (I'm hoping that the parent ports will be unaffected, and so
our existing build procedures continue to build correctly)
How will we (the users/admins) track or be informed of changes or better,
planned/soon changes? (will changes to ports, particularly parent ports,
be co-ordinated through UPDATING or perhaps a new FLAVOURS file if the
parent is say a stub and the real decisions are relocated to slaves?)
Will there be any guidance regarding how flavours/packages should be
created or the criteria for creating sub-packages (secure/insecure; all
options on/off; most useable options on; most liked by the maintainer; most
likely to be used for a datacentre; most likely to be used for desktops;
...)? Will "The Porter's Handbook" be updated for things like criteria;
naming conventions etc?
For folks (like me) that build entirely from source and customise options
to build the applications, how will flavours/subpackages be of benefit?
Will the ability to customise ports, as they exist today, remain? Will I
even notice a change?
I'd like to plan ahead to make this transition seemless and continue to use
FreeBSD and the excellent ports system as we do now.
I started with FreeBSD 2.2.8. There were packages available from the
FreeBSD website. It was a terrific aid. We also enjoyed the different
flavours of jail that were provided by ezjail. However over time, both
evolved as did our expertise to customise our ports (~200 custom ports) and
Jamie Gratton evolved the jail system to eliminate our need of the
excellent ezjail tool. So I can see merit in, what very little I'm
guessing of, the next evolution of ports.
Aside: we already build different package configurations from existing
ports' source. (eg different bind910 with/without kerberos; different
samba44's; simultaineous building of dhcp-[server|client|relay] etc)
I look forward to being on the same page and to understand where this is
going, the likely/potential impact; the naming conventions; etc.
Kind regards, Dewayne.
More information about the freebsd-ports