Date: Mon, 31 May 1999 07:10:10 -0700 (PDT) From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) To: mladavac@metropolitan.at Cc: luigi@labinfo.iet.unipi.it, freebsd-ports@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: a two-level port system? (fwd) Message-ID: <199905311410.HAA51369@silvia.hip.berkeley.edu> In-Reply-To: <55586E7391ACD211B9730000C1100276179631@r-lmh-wi-100.corpnet.at> (message from Ladavac Marino on Mon, 31 May 1999 15:22:33 %2B0200) References: <55586E7391ACD211B9730000C1100276179631@r-lmh-wi-100.corpnet.at>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: Ladavac Marino <mladavac@metropolitan.at>
I don't really have time to butt in (I have to hop on a plane in a few
hours and I haven't finished the presentation slides) but I'd like to
throw in my two cents before this gets out of hand.
* [ML] This would offer an advantage over the existing system
* only if all ports are updated to the new schema, which is a lot of work.
* shar approach could be easily mechanised, and requires no changes in the
* makefiles or the ports themselves. OTOH, shar offers no advantages to
* the folks who build all ports (or most of them) because they end up
* creating all directories anyway. I think Satoshi is the only such
* person :)
I don't think that's really an issue. The question is, what is the
problem you are trying to solve here? What are the requirements of
the system?
The requirements are:
@ Easy to maintain. I have a tree checked out, I can go in there
and type "make package", tweak the Makefile and type "make clean
package", and type "cvs commit" when I'm done. A lot of
committers work this way. Can you beat this?
@ Version control. Can you check out an arbitrary version of any
file? I want to do something like "give me the changes in
Makefile between yesterday and today".
@ Low on bandwidth. CVS combined with "individual files" approach
is pretty darn efficient when it comes to not sending more than
what changed.
@ Easy to search. Does it let me grep something in all md5 files or
all PLISTs?
The current approach does this by letting the filesystem take care of
the individual files. A shar file per port solution is just moving
part of the problem from the kernel (filesystem) to userland
(shar/unshar).
Now, the problems are:
@ It takes a long time to...what? cvsup the tree? That's already
pretty fast. Read all files? Why do you want to read all files?
It's more likely that you want to read all the Makefiles or all
the md5 files or some such, which shar will slow down
considerably. CVS update the entire tree? Ok, so that's pretty
slow. But do people really do it often enough to hurt?
@ It is large. Ok, so it's 44MB (the first poster had the size
completely wrong -- probably had some distfiles or work/ subdirs
lying around). That's less than 20KB per port. Ok, so you can
keep only the Makefile, or even less, and let the network do the
work for you whenever you type something. But does anybody have a
system that has such a wonderful network connection but yet can't
spare 44MB of disk space?
It seems to me that you guys are arguing about a problem that doesn't
really exist. Or at least all ideas proposed so far seem to hurt more
than help. ;)
Satoshi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905311410.HAA51369>