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+
ports.
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
bsd.port.mk. 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
http://www.freebsd.org/ports/ 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.
Doug
--
This .signature sanitized for your protection
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"