At 11:45 AM 2/10/00 -0800, Matthew Dillon wrote:
>
>:> contain.
>:
>:Here's what we can do. We keep all the "major" subdirectories in
>:place, such as audio, devel, etc. BUT, instead of branching out into
>:separate subdirectories, we can just put everything into the
>:Makefile. For example, here are some subdirectories in
>:/usr/ports/audio:
>
> Ouch. I think this is a big mistake. The one-directory-per-port
> scheme works extremely well, it doesn't make much sense to get rid
> of it, and it doesn't make much sense ripping the *working* ports scheme
> to shreds when a simpler solution is available.
In the context of CVSup server connections it would not be. Have to
chuckle when I hear someone doing CVSup for ports-all. Unless they have a
reason, but as we know many will do man things blindly.
> All I would propose is that those subdirectories do not need to be part
> of the base distribution -- that typing 'make modulename' in the parent
> directory (e.g. typing 'make ssh' in ports/security) would first download
> the subdirectory and then do a normal make within that subdirectory.
Sounds good, but again how will the CVSup file for ports and CVSup itself
deal with this. Either a "refuse" file would need to be created and then
populated or there would need to be other changes. Not sure Mr Wraith or
the CVS maintainers would like to break down all the ports and have a
*huge* CVSup file for ports. Or some other method would be needed that
would increase the complexity of how the ports source is handled.
> The initial ports distribution would thus only be a few dozen
> directories and a single Makefile in each one.
But there are several goals:
A faster, more simple install would be good.
Reduced inode usage, less dirs to walk, etc..
Done in a manner to keep updating simple.
What you (and others) have suggested covers the first 2, but then what
happens when someone decides to update their source. Your suggestion would
mean that to first get the source for the port, but then how does one keep
it up to date. Not to mention the ports maintainer(s) might end up jumping
through more hoops. Guess that should be added to the list, as well as not
relying more the source repositories and mirrors.
All irrelevant if hitting a mirror every time 'make <port>' to grab the
source (initial or update) will not be an ongoing load issue for the
servers. Still, what if I just want the source? Something like 'make
source' will be needed or 'make fetch' will need to cover that.
Just trying to cover all bases here and should sub to -install and see
what's going on.
Jeff Mountin - [EMAIL PROTECTED]
Systems/Network Administrator
FreeBSD - the power to serve
'86 Yamaha MaxiumX (not FBSD powered)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
