Suggested improvements for ports

[Doug Barton]

Paul Schmehl wrote:
> --On January 11, 2008 9:24:36 PM -0800 Doug Barton <dougb at FreeBSD.org> 
> 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