Third "RFC" on on pkg-data ideas for ports
apeiron at comcast.net
Mon May 24 11:38:50 PDT 2004
On Mon, May 24, 2004 at 00:07:34 EDT, Garance A Drosihn scribbled these
> The third proposal is basically:
> a) move most "standard" files into a new pkg-data
> file, as described in previous proposals, except
> for pkg-descr and "patch" files.
Yuck. I don't want to have to navigate a large file just to see how
to enable something or change something for a port, or check its plist,
And, how do you suppose 'make' will work? Are you suggesting hard-coding
it to read pkg-data files? That's extremely kludgish. Alternatively, are
you supposing a totally new command structure to build ports? If so, I
commend you for your audacity and bravery. Good luck getting your idea
accepted, and keep in mind that you'll be breaking many, many scripts
and programs (portupgrade not the least of which...).
> b) create a new directory at the root directory of
> the ports collection. That directory would be
> called "Patches", and inside would be a directory
> for each category. Inside each Patches/category
> directory would be a single-file for each port
> in that category, where that single-file would
> have all the "ports-collection patches" for the
> matching port.
What's wrong with files/ ? Remember, there are things in files/ that
aren't always just patches. Take a look at net/dictd/files for example.
If you plan to keep files/ for non-patch files, I don't like that idea
either. I don't want to have to use three '../'s to switch between
viewing non-patch files and viewing patch files. See below about "more
> c) [minor] in the pkg-data section for distinfo, I'd
> like to change the format for each file from, eg:
> MD5 (bash-2.05b.tar.gz) = 5238251b4926d778dfe162f6ce729733
> SIZE (bash-2.05b.tar.gz) = 1956216
> 5238251b4926d778dfe162f6ce729733 1956216 bash-2.05b.tar.gz
I don't have a problem with this, as it increases the scriptability
factor. Though I'd prefer to see that replace distinfo, rather than go
into your panacea file.
> result in as dramatic a drop in inodes, but it has the nice
> side-effect that Patches are separated from all the other files.
In all honesty, why would you want to do that? It's just more typing.
And from the perspective of a Perl programmer, that's a Cardinal Sin,
as it breaks the Holy Virtue of Laziness.
> Thus, end-users could 'cvsup refuse' the patches for categories
> that they do not care about, and it would not break operations
> which work on the entire ports collection (such as `make index').
Not that I've tried this, but ... can't you just use a mask like
ports/graphics/*/files/ or such to refuse patch files?
> So, should we pursue any of this?
I like the idea of item c, with the proviso that I added. I wouldn't be
so against all of this if you weren't suggesting things that as I
understand them would require more work for me to garner information
from the ports tree. The whole "all data in one file" idea reminds me
of Microsoft for some reason.
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated". -- Ken Thompson
Unix is user friendly. However, it isn't idiot friendly.
Please CC me in all replies, even if I'm on the relevant list(s).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20040524/d9f37b9c/attachment.bin
More information about the freebsd-ports