Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Sep 2000 22:58:30 -0500
From:      "Jeffrey J. Mountin" <>
To:        asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami)
Cc:        ports@FreeBSD.ORG
Subject:   Re: RFC: Ports layout reorganization (Re: ports tree idea:   Combine DESCR and COMMENT)
Message-ID:  <>
In-Reply-To: <>
References:  <"Jeffrey J. Mountin"'s message of "Fri, 29 Sep 2000 15:02:50 -0500"> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
At 05:38 PM 9/29/00 -0700, Satoshi - Ports Wraith - Asami wrote:

--snip agreement with my quote of Trevor--

One line in the Makefile and one less file to deal with.

>  * Agreed and since the person doing the proposing has to change 
>  * readme target to make the README.html files...  ;)
>You're talking about me? ;)


>As for the COMMENT thing, we don't have to move all at once.  Say, if
>COMMENTSTR is defined, use that as the comment, otherwise use the
>file.  That way ports can migrate slowly, and since there is no need
>for repo copies on this, people can just change them at their leisure.

And then eventually remove the code.  At your leisure of course.

>We could also have portlint warn and addport reject new ports with the
>individual comment file to ensure we won't be accumulating any new

Makes sense.

>  * Moving them to the root and prefixing them means the are visually tied
>  * together and that has value.  One can quickly see if they are there and I
>Yes, that is exactly the point.  Sorry I omitted it in my latest RFC,
>it was in the original discussion but I should have mentioned it.

No omission, just between the lines if you look close. ;)

>  * Speaking of patch naming.  Some like using the file name rather than
>  * patch.  This might be a problem if the patches are moved to files/ and
>  * think that something along the line of patch-<file>-?? would be better
>  * (only have one locally that doesn't start with patch).  Again, visually
>  * grouped and should please most.  I rather like the idea of know what file
>  * the patch is for and not have to open every patch to find something.
>I'm not sure how you got the impression that patches were going to
>lose the "patch-" prefix.  They won't.  In fact I was planning to just
>repo-copy everything from patches/ to files/ and be done with it.

On oblique reference to several discussions on patch naming.  Only brought 
it up to point out the visual grouping possible *should* patches be moved 
to the main dir....

>Whether the individual patches are called "patch-[a-z][a-z]" or
>"patch-<filename>" are up to the maintainer.

... like one without the patch- prefix in security/sslproxy and may be 
others, which don't follow the guidelines.

>Yes, it is a personal preference of myself and many others.  I should
>have noted that I don't think losing some directories is benificial if
>it makes the job harder for some of our already overworked committers
>bunch. :)

Which is why I understand the reasoning for the scripts dir...

>  * OK, scripts/ could stay.  What's another 1000 inodes compared to losing
>  * 40,000.  Or 60,000 if files/ goes away.
>You didn't read all of what I typed (I know, most people don't :).  By
>my calculation, there are only 1,756 files/ directories we can get rid
>of by moving all patches to the main directory.  Not all ports have
>patches and many will have things in files/ other than patches.  The
>difference is 8,780, not 20,000.

And since I do not have entire tree could not calculate the savings or 
figure out all the combinations.  While a 50% increase in savings looked 
good for a gross guess, 22% isn't all that bad either. ;)

Yes, I did read all.  Several times.  A bit bruised from the numbers 
flying, but presume that 204 ports will have script/ and also might be one 
of the 2354 with files/ leaving somewhere between 1500-1700 with neither 
after pkg/* moves to the port root, patches/* moves to files/, and 
files/md5's are moved to root and renamed "distinfo" or some other name 
that makes sense and allows for completions.

... and completions makes a better argument to me than columns in 'ls' (use 
an alias for 'ls -l' and the output of 'ls | column -x' better than 'ls' - 
a reading style preference if you will :) to make changing directories easier.

Guess the plan would be to update, portlint, repo-copy, and 
start sucking COMMENT into the Makefile's at it's simplest.  Wonder how 
much time the "reduced directory" tarball will save when unpacking or doing 
a 'find'.

Jeff Mountin -
Systems/Network Administrator
FreeBSD - the power to serve

To Unsubscribe: send mail to
with "unsubscribe freebsd-ports" in the body of the message

Want to link to this message? Use this URL: <>