Re: Re: Idea: embed patch in .info

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