Date: Thu, 8 Jan 2004 21:07:10 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: freebsd-ports@FreeBSD.ORG Subject: Re: Call for feedback on a Ports-collection change Message-ID: <p0602043abc23baee469f@[128.113.24.47]> In-Reply-To: <200401090233.51499.max@love2party.net> References: <p0602041abc1660a416d0@[128.113.24.47]> <200401090233.51499.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 2:33 AM +0100 1/9/04, Max Laier wrote:
>On Friday 09 January 2004 01:49, Garance A Drosihn wrote:
>> Especially as disks get ever-larger, I think we're
>> better off with fewer-but-larger files, instead of a larger
>> number of tiny files.
>
>As disks get lager there is fewer concern about lost space
>(in my personal perception). If one is concered, however,
>she/he could keep /usr/ports on a seperate (smaler) partition
>and be okay. Not a compelling arument to change a working system.
As disks get larger, the minimum size of a file will grow.
More to the point, however, is that the sheer number of inodes
is a headache. If that is not true, then why did the ports
collection just go thru a whole lot of work to remove one file
(pkg-comment) from all the ports?
> > I would also write a single simple program, which knows how
> > to find the correct info for any given purpose.
>
>You will never catch all the (crude) hacks spread all around
>the ports Makefiles and pkg-* with a "simple program".
I suspect I was too brief in my initial message. I had started
with a much-longer message, but figured everyone would give up
on it before trying to read it all...
The simple-program is *only* for pulling information out of the
suggested new file. That's all it will do. You might run it
with a parameter of "patches", and it will create the directory
work/patches
and then fill that directory with files patch.001 through
patch.042. Then the standard port-processing would apply
*those* patch files, instead of each port (as it comes from
cvsup) containing a directory of patch files.
I should stress that I do not expect *all* ports to put *all*
their patches into this single new file. But for ports which
only have a few lines to change, they could put the patch(es)
in this new file instead of separate files.
>1) Changes are much harder to do:
> With the currently used scheme it's fairly easy to add a
> patch when needed.
I do not expect this to get any harder. (of course, I might
be wrong on that)
>2) Changes are much harder to track:
On the contrary, changes should be *easier* to track. All the
information for any given port will be in two files. This will
not be true for all ports (particularly for ports which have a
lot of patch files).
>3) It will get harder to create ports:
I really do not expect this to happen -- particularly since
the simple-program will know how to find the appropriate
information for EITHER old-style or new-style ports. Thus,
it CANNOT be harder to do than it is now, because someone
can just do exactly what they do now and the makefiles will
handle it all.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0602043abc23baee469f>