Date: Fri, 29 Sep 2000 15:02:50 -0500 From: "Jeffrey J. Mountin" <jeff-ml@mountin.net> To: Trevor Johnson <trevor@jpj.net>, Satoshi - Ports Wraith - Asami <asami@FreeBSD.ORG> Cc: ports@FreeBSD.ORG Subject: Re: RFC: Ports layout reorganization (Re: ports tree idea: Combine DESCR and COMMENT) Message-ID: <4.3.2.20000929140626.00c3fa00@207.227.119.2> In-Reply-To: <Pine.BSI.4.21.0009291226160.11091-100000@blues.jpj.net> References: <vqcsnqjin86.fsf_-_@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 01:23 PM 9/29/00 -0400, Trevor Johnson wrote: >I like the idea of having the comments in the makefiles. The DESCR files >as they are already contain a detailed description, and COMMENT a brief >description. A port's Makefile, though, often doesn't have that >information. It doesn't seem to be mentioned in the Handbook >(http://www.freebsd.org/porters-handbook/x54.html#AEN67) but portlint >encourages us to have 24 or fewer lines of text in DESCR files. If the >first line had to be the brief description, I'd want to leave a blank line >beneath it, leaving only 22 lines. Agreed and since the person doing the proposing has to change bsd.port.mk's readme target to make the README.html files... ;) In some cases combining them would should more clearly that some lack a good description. AFAICR, a couple are the same either exactly or in essence. > > pkg-comment > > pkg-descr > > pkg-plist > > (and other pkg files) > >I don't see the value of the pkg- prefix. I do see myself typing two >extra characters ("p" then tab) to work with those files from the shell, >if the prefix is added. 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 need to hit 3 extra keys being an ESC-\ type. > > I do not like moving all the patches into the main directory. It's > > not only the number of patches, but the unpredictability of the > > directory listing caused by different lengths (more variations now > > with filenames included) and number of patches. I want to know where > > to look for my stuff when I do a "ls". :) > >The OpenBSD-style naming I proposed would retain the patch- prefix for >patches. That would keep them all in the same place unless you used the >-t option to ls. 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. > > or heaven forbid: > > > > === > > ## ls > > total 21 > > 1 CVS/ 1 patch-ac 1 pkg-comment > > 1 Makefile 1 patch-ad 1 pkg-descr > > 1 checksum 1 patch-af 1 pkg-plist > > 1 files/ 1 patch-ag 2 > scripts-create-dev-link* > > 3 patch-aa 1 patch-ai > > 3 patch-ab 1 patch-ba > > === > >I could live with this, even if the patches had longer names that forced a >single-column listing. I realize that some porters cannot. It would nuke another directory. Not sure I agree with PW's reasoning: > I do not like moving all the patches into the main directory. It's > not only the number of patches, but the unpredictability of the > directory listing caused by different lengths (more variations now > with filenames included) and number of patches. I want to know where > to look for my stuff when I do a "ls". :) Sounds more of a personal preference when using 'ls' to view things. Don't care to argue with the Wraith, but he did RFC. Losing 2 directories is great, but why not all of them. To be sure, some will end up with very ugly main directories (postfix-current has 61) that some will not enjoy viewing. Most only have a small number of patches. OK, scripts/ could stay. What's another 1000 inodes compared to losing 40,000. Or 60,000 if files/ goes away. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.20000929140626.00c3fa00>