Am Samstag, 12.07.03 um 01:00 Uhr schrieb David R. Morrison:
I'd like to weigh in on this again. I played around for a while today
with
making shar archives out of a combination of info and patch files,
using
/usr/bin/shar (which is BSD shar). The resulting file is quite similar
to the original proposal of tacking the patch file on to the info file,
but because it is a shar archive there is no ambiguity about it. And
as
you can see from the example I will paste below, it is quite readable
(by humans): after a bit of header stuff, you see the original info
file
with an X at the beginning of each line... then there is some
intermediate
stuff, and you see the patch file with an X at the beginning of each
line.
It does mean, however, that Fink has to first run the file through a sh
process before even being able to process it. If you thought Fink was
slow in parsing .info files now, just wait till it fires up several
thousand sh processes to parse all .info files :-)
In fact, I would venture to say that if you were only trying to make
small
changes to the info file, you could edit this file directly, without
unshar-ing it to its component parts.
I agree with Max, up to a point, that anybody somebody sends you the
info
file they should send you the corresponding patch file, and that
checking
out from CVS by date could deliver you the appropriate pair. But this
is
not so robust, it seems to me... somebody could forget, you could
store the
files someplace where it wasn't obvious what corresponded to what, it
could
be tricky to determine the date you need, and so on.
Directly modifying a .shar archive is more robust? I think not-
The shar archive solution is not a bad compromise.
Well, to me it it is :-) While it is probably the quickest way to hack
this feature in, it doesn't seem very attractive to me at all.
I still feel as if a non-problem is hyped up here and made into a
problem, when it isn't really. Yeah, I can mix up the Installer.app
from 10.1 and 10.2 - in fact, on my computer where I have several OS X
partitions, my OS X 10.2 regularly starts the 10.1 Installer.app. I
always reset it to use the 10.2 one then, but still, every now and
then, it decides to revert to the 10.1 Installer.app. I have no idea
why, but still I don't think that should prompt Apple into merging all
system files into a single file, to prevent this problem. Rather, I
know that a) I have a very unusual setup and b) the problem is very
easy to avoid / fix for me. The drawbacks of having all system related
things in a single file simply doesn't justify the minimal gain.
Max
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
|
