Date: Fri, 11 Jan 2008 21:24:36 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Paul Schmehl <pauls@utdallas.edu> Cc: FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: Suggested improvements for ports Message-ID: <47884F14.3040708@FreeBSD.org> In-Reply-To: <ED8842DFA28376008F3CA3A4@utd59514.utdallas.edu> References: <ED8842DFA28376008F3CA3A4@utd59514.utdallas.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47884F14.3040708>