Call for feedback on a Ports-collection change

Garance A Drosihn drosih at rpi.edu
Thu Jan 8 18:07:22 PST 2004


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 at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu


More information about the freebsd-ports mailing list