Date: 29 Sep 2000 17:38:14 -0700 From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) To: "Jeffrey J. Mountin" <jeff-ml@mountin.net> Cc: Trevor Johnson <trevor@jpj.net>, ports@FreeBSD.ORG Subject: Re: RFC: Ports layout reorganization (Re: ports tree idea: Combine DESCR and COMMENT) Message-ID: <vqcg0mihfyh.fsf@silvia.hip.berkeley.edu> In-Reply-To: "Jeffrey J. Mountin"'s message of "Fri, 29 Sep 2000 15:02:50 -0500" References: <vqcsnqjin86.fsf_-_@silvia.hip.berkeley.edu> <4.3.2.20000929140626.00c3fa00@207.227.119.2>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: "Jeffrey J. Mountin" <jeff-ml@mountin.net> * >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. Good point. This also emphasizes the reason why I don't like combining the two files -- too much manual editing required. * Agreed and since the person doing the proposing has to change bsd.port.mk's * 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. 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 ones. * >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 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. * 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. Whether the individual patches are called "patch-[a-z][a-z]" or "patch-<filename>" are up to the maintainer. * 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. 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. :) * 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. -PW 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?vqcg0mihfyh.fsf>