Date: Sat, 12 Jan 2008 13:45:39 -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: <47893503.5040604@FreeBSD.org> In-Reply-To: <C65806EC3DF5B1A0EFA06B0E@paul-schmehls-powerbook59.local> References: <ED8842DFA28376008F3CA3A4@utd59514.utdallas.edu> <47884F14.3040708@FreeBSD.org> <C65806EC3DF5B1A0EFA06B0E@paul-schmehls-powerbook59.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Schmehl wrote: > --On January 11, 2008 9:24:36 PM -0800 Doug Barton <dougb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47893503.5040604>