Paul Schmehl wrote:
--On January 11, 2008 9:24:36 PM -0800 Doug Barton <[EMAIL PROTECTED]>
wrote:
First, thanks for you answer. Second, a clarification. I started this
thread from the viewpoint of a port maintainer (I maintain about 10
ports) who is concerned about confusing users.
Thanks for clarifying that. I will therefore snip the bits that we agree
on below. :)
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.
Interesting. I haven't used portmaster because I'm used to doing things
the "traditional" way. I *thought* portmaster was a
replacement/improvement of portupgrade,
"Alternative" to portupgrade is probably the right way to phrase that.
Portupgrade does a lot more stuff, and portmaster has no ability to
install packages.
However both tools are just as good at installing things as they are at
upgrading them. The distfiles for portmaster consist of just the /bin/sh
script and the man page, so you can install the port, read the man page,
and if you're not interested just delete it. Also there is a 2.0-beta
version of portmaster at http://dougbarton.us/portmaster. The --help is
up to date for the new version, but I haven't finished updating the man
page for the new features yet. The old man page still applies for
everything else though.
Another thing
that used to confuse me was the existence of multiple ports for the same
software. For example, bash and bash2. It took me a while to realize
that bash was the *current* version and bash2 was the *older* version.
If you look, however, at the apache ports or the mysql ports, they
always append the version number. This makes it easier for the user to
understand, without having to do a great deal of research, what each
port actually is. This, perhaps, is an area where standardization would
benefit the community without creating undue rigidity.
I have actually advocated in the past that ALL ports should have version
numbers, and that we then create virtual ports (symlinks, whatever) that
point to whatever is the "current" version of that software. Different
developers dislike that idea for different reasons, but my opinion is
still that from the user perspective this would make life a lot easier.
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.
Really? Some ports use PLIST_SUB and use those macros in pkg-plist.
Others do not - they use the relative path entirely.
That is plain wrong, and should not happen.
I don't recall
anything in the handbook that says you must or should use one or the
other. Here again is an area where standardization might improve
clarity.
Agreed.
The use of unexec is also not clear. Should I go to the
trouble of checking to see if the conf file has been altered and remove
it if it hasn't been?
Yes. You're right again here that this needs to be better documented.
... re pkg-descr ...
I'm not looking for a cookie cutter approach, but I think the use of
"must", "should" and "may" in the docs would be helpful. For example,
you "must" have a WWW: in pkg-descr if there is one available. You
"should" create a brief description of what the port does. You "may"
use a cut and paste of the vendor's explanation but be careful to make
sure it isn't so generic that it doesn't make sense to FreeBSD users.
Sure, that sounds reasonable. I'd change the one about WWW to a SHOULD,
but IMO you're on the right track here.
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.
Not as easy as you think. I maintain a port that creates files and
directories. The first time the app is launched *new* files *and*
directories are created in those directories - files and directories
which have names that I can't possibly know at the time of port
creation.
That's unfortunate. :) Depending on what kind of data we are talking
about, you might consider putting it in /var. If it's not something that
needs to be preserved across reboots, putting it in /var/run would solve
several problems at once.
The other option is to add a message on deinstall that tells the user
how to delete this stuff themselves if they won't use the port anymore.
hth,
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]"
