Suggested improvements for ports

Doug Barton dougb at
Fri Jan 11 21:24:44 PST 2008

I'm going to try to combine your two posts so that I can answer in one, 
my apologies if I scramble something.

Paul Schmehl wrote:
> Some of this has been discussed ad infinitum, but, in an off-list 
> conversation, I came up with this list of suggested improvements for 
> port.  I'd like to see these things done, but I'm not sure how.  Improve 
> the docs?  Create a checklist?
> 1) You can't build a dependent port and first set the config for the 
> options that you want.  So, when you select sasl in postfix, you never 
> get the chance to check the saslauthd option, for example.

Portmaster actually does a depth-first traversal of the dependency tree 
which allows you to do this.

That said, I think there are 2 additions it would be nice to make to the 
OPTIONS framework to aid the situation you describe. One would be having 
OPTIONS "inherit" default settings from the environment, so that if the 
user has a global option set, that same option in a port's OPTIONS block 
always comes up the way the user specified, unless ...

The other thing that would be really great is something like 
"super-options" that a port could set that would enforce that option in 
the dependent ports (or generate an error if in conflict with the user's 
global options). Bonus points if this super-option could trigger the 
rebuild of an existing port/package to get the stuff it needs.

With the super-option idea, if you MUST have saslauthd support in order 
for something to work (and I'm just picking up on your example, no idea 
of this specific case is meaningful or not) then "the right thing" would 
happen all the way down the chain. This would of course require some 
large amount of coordination between port authors, but a lot of the 
standardization you'd need is already de facto.

> 2) There's no standard for some of the details of port building.

Now you're mixing in "developer" issues with "user" issues. The user 
should never have to see the details you're describing here, although if 
(as I gather from later in the thread) your desire is improved "how to" 
docs for ports creation, than I support that goal.

> it's entirely up to the port maintainer and the committer to decide how 
> to build the port.  The postfix port maintainer *could* include a 
> dependency for saslauthd. He chose not to.  He *could* include a note in 
> pkg-message that warns you that saslauthd needs to be installed as 
> well.  He chose not to.  His choices are both reasonable and customary, 
> but they don't serve the customer well.

Now here you have to be careful. The way we handle this problem is for 
those who want/need saslauthd-related postfix to create a 
postfix-saslauthd version, and handle that support themselves. Bonus 
points if you can do it as a slave port, but that isn't always the case. 
Please note, I'm not speaking theoretically here, I've been on both 
sides of this issue, and so (modulo the prospect of user confusion with 
N * M different varieties of the same port) the system works.

I should also point out that I've had my arm twisted by users to support 
things in my ports (particularly pine/alpine) that I cannot test for 
myself (particularly maildir) and so I have done so with the caveat that 
support for those features _must_ come from the community, or I'll rip 
them out of the port the first time they break something. This method 
also works. :)

> 3) There's no standard for the format of pkg-plist,

This has already been covered, but for the record you're wrong about that.

> pkg-message or 
> pkg-descr, so port maintainers are free to put whatever they want in 
> there. 

There are rough guidelines (portlint will prod you on both of those, 
especially pkg-descr) but you're right, no hard and fast rules. I don't 
remember the latin version, but there is a very old saying to the effect 
that "the one doing the work gets to decide how the work gets done." 
Guidelines are good here, cookie-cutter approaches don't scale to 18k+ 

> There's a customary way of doing it, but it's not set in stone 
> and variations are found throughout ports.

You (pl) need to wrap your head around the fact that this is, and always 
will be the status quo. If you want rigid rules, go create your own 
ports system.

> What's the limit on the number of files you can put in PLIST_FILES? Directories in PLIST_DIRS?  Is there any requirement to use pkg-plist? 

Don't take this the wrong way, but why do you care? If you are asking 
because you want to write a port, it's a reasonable question, and should 
probably be given a more thorough treatment in the handbook. However, 
this precisely the kind of thing for which "community" takes on real 
meaning. If you get confused by this, just send a message to the list. 
"I am trying to port FUBAR-1.23, and I'm wondering if ...." and you will 
generally get at least one answer. Hopefully if you get more than one, 
they won't conflict. :)

> When do you use @dirrm as opposed to @dirrmtry? 

That's an easy one. If the directory might have files in it from another 
port, use the latter. If your port is the only one putting files in it, 
the former.

> How are conditionals handled in pkg-plist? 

PLIST_SUB. It's probably also worth noting here that a lot of these 
questions can be answered by reading through at least the first part of It actually documents most of this stuff pretty well, and 
the descriptions are generally kept well in synch with the code.

You also asked a question about the use of WWW: in pkg-descr. It's 
encouraged, since the automated tools make use of it (e.g., see and bore down to some specific ports) but 
not mandatory.

> 4) There's no standard for config files.

Someone else already answered this one for you.

Finally, I'd like to make a suggestion for you to do more work. :) The 
more time you spend on something (like ports) the harder it is for you 
to "see" things through the eyes of a new user. This is doubly true for 
writing documentation about it. I try to add useful stuff where I can, 
but life would be really great if you could take the time to document 
your questions more thoroughly, maybe with some collected answers, and 
start hacking away at the current docs. If you're not keen to learn the 
SGML there are people who can help you with that, but coming up with 
good content that covers the needs of people like you can (somewhat 
ironically) be done most easily by people like you. I hope this is a 
good start.



     This .signature sanitized for your protection

More information about the freebsd-ports mailing list