Max Horn said: > Tackling this by using a whole > new format (be it ar, tar, gzip, shar, or anything else) seems like a > big step to me. One of the core strengths of Fink is how easy it is to > make packages for this. That's largely due to the fact that packages > are simple text files. Diverting from this in any way IMHO degrades > this strength of Fink, even if we provide "easy" commands to achieve > it.
I agree with Max, to a certain extent. I guess I'm not convinced that there's a need for archive formats. I kind of like the idea of simply modifying the .info parser to stop where the patch begins, and taking advantage of the fact that patch will strip off the rest of the .info file. Then again, while combining the two is as simple as 'cat $name.info $name.patch', extracting the two requires a script. Someone who is really behind this idea needs to come up with a simple prototype to show just how easy it is (I'm skeptical about something more complicated than a single patch file). > So far I have yet to personally experience actual advantages of the new > "%n.info" scheme (I am curious, folks: tell me your success stories, > things you were able to do with the new system which you couldn't do in > the past. I am talking about real experience, no theoretical scenarios, > please :-) Just the other day, I couldn't connect to the SF cvs server, so I grabbed the tarball of the repository (wasteful of bandwidth, perhaps-- but less CPU intensive, and I figured I would be grabbing about a month's worth of updates anyway if only I could connect via pserver). I was surprised to find out that the repository was over 250 MB (if memory serves). I don't have any numbers to show how much smaller the repository could have been if the %n.info naming scheme had been around since day 1, but deleting files and adding new ones almost completely defeats the purpose of storing the files in CVS. If you estimate that less than 25% of the .info file changes for each revision, that's still a substantial size savings. I'm sure that having a whole load of ,v files in the repository attic doesn't help out the CVS server performance, either. (Remember, this isn't theoretical, just poorly quantified :-) If pressed, I might even produce some real numbers.) For anyone advocating staying with %n-%v style names, would you consider coming up with some sort of equivalent for 'cvs diff' between versions of the .info files? Trying to figure out what changed between .info files is very difficult over unreliable HTTP+viewcvs connections, since you have to click "show attic" and wait for every single old version of all packages in that category to load. I'm not even sure if there's a good way to do it from the command line (without knowing the exact filename of the old .info file). The %n-%v stuff would be fine if we had a system like BitKeeper (no flames please; I'm just stating capabilities) or Subversion (I think) which can track file renames. Then, the equivalent of 'cvs diff -D yesterday' would compare a given .info file to its (differently named) predecessor. -- Charles Lepple <[EMAIL PROTECTED]> http://www.ghz.cc/charles/ ------------------------------------------------------- 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 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
