Re: [Fink-devel] Re: Idea: embed patch in .info
Am Dienstag, 15.07.03 um 13:01 Uhr schrieb Chris Zubrzycki: On Saturday, July 12, 2003, at 09:18 PM, Max Horn wrote: Am Sonntag, 13.07.03 um 01:47 Uhr schrieb John Davidorff Pell: It was mentioned soon after all this was suggested in the first place, by i don't know who, to do it like this: %n.info and %n-%v-%r.patch. basically only renaming the info file, not the patches. this is an obviously simple solution and will work just as well as previously and won't have any of the disadvantages that are being discussed now. That approach works nicely for me. What do others think? You lose the key advantage of being able to make mass changes (scripted) that require a revision update, because once the file revision and patch are out of sync fink can no longer find the patchfile. Honestly I do not see the problem of using the $Id $ tags in files and using -D with cvs commands to get a specific snapshot. This is meant to make things easier, not harder on us. Well I don't see a problem either, so personally I'd be fully happy with what you suggest Chris (it's what I myself proposed earlier, after all). But it seems others see a problem... Max --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Idea: embed patch in .info
On Wednesday, July 16, 2003, at 09:17 AM, Max Horn wrote: Am Dienstag, 15.07.03 um 13:01 Uhr schrieb Chris Zubrzycki: On Saturday, July 12, 2003, at 09:18 PM, Max Horn wrote: Am Sonntag, 13.07.03 um 01:47 Uhr schrieb John Davidorff Pell: It was mentioned soon after all this was suggested in the first place, by i don't know who, to do it like this: %n.info and %n-%v-%r.patch. basically only renaming the info file, not the patches. this is an obviously simple solution and will work just as well as previously and won't have any of the disadvantages that are being discussed now. That approach works nicely for me. What do others think? You lose the key advantage of being able to make mass changes (scripted) that require a revision update, because once the file revision and patch are out of sync fink can no longer find the patchfile. Honestly I do not see the problem of using the $Id $ tags in files and using -D with cvs commands to get a specific snapshot. This is meant to make things easier, not harder on us. Well I don't see a problem either, so personally I'd be fully happy with what you suggest Chris (it's what I myself proposed earlier, after all). But it seems others see a problem... as an added idea, for the people that think they will have trouble keeping track of such patches, they can add either an empty file w/the version/revision of the patch as a name, or they can do echo version-rev package.patch diff -ruN dir dir.new package.patch problem solved :) -chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 Security Is A Series Of Well-Defined Steps... chmod -R 0 / ; and smile :) --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Idea: embed patch in .info
On Saturday, July 12, 2003, at 09:18 PM, Max Horn wrote: Am Sonntag, 13.07.03 um 01:47 Uhr schrieb John Davidorff Pell: It was mentioned soon after all this was suggested in the first place, by i don't know who, to do it like this: %n.info and %n-%v-%r.patch. basically only renaming the info file, not the patches. this is an obviously simple solution and will work just as well as previously and won't have any of the disadvantages that are being discussed now. That approach works nicely for me. What do others think? You lose the key advantage of being able to make mass changes (scripted) that require a revision update, because once the file revision and patch are out of sync fink can no longer find the patchfile. Honestly I do not see the problem of using the $Id $ tags in files and using -D with cvs commands to get a specific snapshot. This is meant to make things easier, not harder on us. -chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Albert Einstein --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
On Friday, July 11, 2003, at 01:04 PM, Max Horn wrote: Personally, I am very much biased against this whole idea. But let's look at it rationally. I agree with max, i don't like this. If you want to embed a small patch in your info file, you can do it with PatchScript as many packages do.. -Ben --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
I completely agree with this. Just to voice an extra opinion, I'm not for the info+patch file style On Sunday, July 13, 2003, at 12:50 PM, Ben Hines wrote: On Friday, July 11, 2003, at 01:04 PM, Max Horn wrote: Personally, I am very much biased against this whole idea. But let's look at it rationally. I agree with max, i don't like this. If you want to embed a small patch in your info file, you can do it with PatchScript as many packages do.. -Ben --- 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 --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
Am Freitag, 11.07.03 um 23:53 Uhr schrieb Daniel Macks: [...] A quick look at unstable/utils finds 20 or so packages where the .patch and .info have different rev's as a result of the -dev essentials fix, validator fixes, checksum additions, Source changes, typos. So one would have to bump the (CVS) rev of a corresponding .patch whenever this happens. All-told, about a third of the files there have rev1.1, meaning something has changed without bumping up %v-%r. You are making the incorrect assumption that files are matched via the revisions. That is not true in CVS in general. Rather, you would match them via the date, or by release tags. File revisions in CVS should *never* be used to match files in CVS. Hence I do not consider your argument given above as valid. [...] I agree with the think long and hard before changing formats. That's why the things I had proposed in previous messages were pretty much just stringing the current files together (cf. an actual archive format), and keeping it transparent and optional. BTW for everybody who didn't notice; if your patches are short, it's already today rather trivial to integrate them into the .info file by embedding them into the PatchScript. A combination of CVS tagging the .patch with %n-%r and using Patch-MD5 (as people suggested recently) would solve both sync problems I think? An .info could never use a wrong .patch, and one doesn't have to worry about keeping CVS rev#s in sync. Patch-MD5 sounds more acceptable to me than a format change. And tagging revisions, well it could be done, but mostly for convenience, to make it easier to check out a given ver/rev. -D checkouts will already make it possible to get the matching patch. Okay, what if we tag .patch, and then change from having the .patch in the tree to being something that is downloaded during build? Bad idea. That would mean you have to have an online connection to build; and even if we cache the .patch files like we cache source files in /sw/src, it would mean that the .patch files have to have the %n-%v-%r.patch name again, and we have to keep all .patch versions ever around on our server - after all, not everybody is using latest CVS, so we can't just only provide the latest patch as %n.patch. Cheers, 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 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] 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 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Idea: embed patch in .info
Hi Max. Well, actually I was thinking that fink could parse the shar archive directly, and only unpack it if it was building a package (in order to extract the patch file). The algorithm: 1) ignore all lines at the beginning not starting with X 2) while the line begins with an X, drop the X and parse as usual 3) when you reach the line that begins with END, stop and ignore the rest of the file. And the kind of hand-editing I was thinking of was of the sort where all you need to change is the version number and Source-MD5, or maybe add a missing dependency, or something like that. The info part of the shar archive could easily be edited in that case. -- Dave --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
Personally, I am very much biased against this whole idea. But let's look at it rationally. The only reason I saw when browsing through the thread was a concern regarding matching a .info file with the correct .patch file for it. Please correct me if i missed any other reasons. Now, let's see whether 1) this is actually a problem, and 2) if it is, how to tackle it. Regarding 1) If you get a fink .info/.patch pair from somebody, that person is pretty much expected to send you a matching pair. If you get latest CVS, you get a matching pair. If you get a CVS checkout of a specific data - you still get a matching pair, as long as developers follow the rule of submitting modifications to the .info and .patch at the same time. This is the only correct behavior for any developer anyway. So - could somebody please tell me any scenario where this problem really is a problem? Except for cases were people manually modify the .patch file, of course. Regarding 2) Next, let's say there are really cases where its possible for an unwanted incorrect .info/.patch matchup. 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. So IMHO there should be really strong reasons to do this. I'll wait for answers to 1) before I give my final opinion on whether this feature is worth such a change, but right now it looks to me (again my personal opinion): nope, it doesn't. The other solution which nobody mentioned yet (or maybe I missed it), is rather trivial: we go back to the old scheme of renaming the .info/.patch file for each version/revision. Personally I like that solution much better than any .info/.patch combination technique. 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 :-) That said, I am supporting whatever turns out to be the best for Fink. But I'd suggest carefully considering what we are doing, and why. Cheers, 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 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Idea: embed patch in .info
Am Freitag, 11.07.03 um 22:22 Uhr schrieb Benjamin Reed: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Horn wrote: The other solution which nobody mentioned yet (or maybe I missed it), is rather trivial: we go back to the old scheme of renaming the .info/.patch file for each version/revision. Personally I like that solution much better than any .info/.patch combination technique. 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 :-) I don't see how there will be any success stories until enough time passes that packages that are currently unnumbered undergo revision. The advantage in the new naming scheme is being able to see the history, and until you start updating packages, there will be no history. :) Point taken, you are right of course! Still I'd be interested to know if somebody has already had any real experiences with this (independent of the subject of the thread, actually). E.g. I converted a few of my packages to the new scheme, but did not yet update any of them again. I wonder if people maybe already have had a chance to make use of the see the history more easily feature. Cheers, 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 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Idea: embed patch in .info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Horn wrote: Point taken, you are right of course! Still I'd be interested to know if somebody has already had any real experiences with this (independent of the subject of the thread, actually). E.g. I converted a few of my packages to the new scheme, but did not yet update any of them again. I wonder if people maybe already have had a chance to make use of the see the history more easily feature. I've used it extensively in my exp tree to tell what I changed in KDE packages and stuff. I use that pattern of behavior (things like 'cvs log foo' and then doing a diff against certain milestone revisions) all of the time in other projects too. It's also a good way to see what's changed since a given time, eg, you can do cvs diff -D date on an info file to see what's been modified. I can tell you now that even if no one else gets any use out of it, I will be using it constantly. :) - -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ Standards are the industry's way of codifying obsolescence. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/DyMmUu+jZtP2Zf4RAjxDAKCL/bakYyTTycBxu29EF8+BU0UYPgCgnNdV Z9RMNfTtgz1EoKCTLzTQkyw= =VjV9 -END PGP SIGNATURE- --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
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
Re: [Fink-devel] Re: Idea: embed patch in .info
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.
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.
The shar archive solution is not a bad compromise.
-- Dave
P.S. I picked zip because the info and patch were not too big.
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# zip.info
# zip.patch
#
echo x - zip.info
sed 's/^X//' zip.info 'END-of-zip.info'
XPackage: zip
XVersion: 2.3
XRevision: 2
XMaintainer: Dave Vasilevsky [EMAIL PROTECTED]
XLicense: BSD
XCustomMirror:
Xnam-US: http://uiarchive.uiuc.edu/mirrors/ftp/ftp.info-zip.org/pub/infozip/src/
Xnam-US: ftp://uiarchive.cso.uiuc.edu/pub/ftp/ftp.info-zip.org/pub/infozip/src/
Xeur-UK: http://www.mirror.ac.uk/sites/ftp.info-zip.org/pub/infozip/src/
Xeur-PL: ftp://sunsite.icm.edu.pl/pub/unix/archiving/info-zip/src/
Xeur-CH: http://sunsite.cnlab-switch.ch/ftp/mirror/infozip/src/
Xeur-CH: ftp://sunsite.cnlab-switch.ch/mirror/infozip/src/
XPrimary: ftp://ftp.info-zip.org/pub/infozip/src/
X
XSource: mirror:custom:%n23.tar.gz
XSource-MD5: 5206a99541f3b0ab90f1baa167392c4f
XSourceDirectory: %n-%v
XDocFiles: BUGS CHANGES INSTALL LICENSE MANUAL README TODO WHATSNEW WHERE
XHomepage: http://www.info-zip.org/pub/infozip/Zip.html
XDescription: Compression compatible with pkzip
XDescDetail:
XZip is different from gzip in that it allows packing multiple files into a
Xsingle archive (without the assistance of tar). It is compatible with pkzip,
Xpkunzip, and other Windows zip utilities.
X
XThis utility is necessary to install several packages in a pure Darwin
Xinstallation, as Darwin does not come with zip/unzip.
X
XPatch: %n.patch
XCompileScript: make CC='gcc -prebind' -f unix/Makefile generic
XInstallScript: make -f unix/Makefile install BINDIR=%i/bin MANDIR=%i/share/man/man1
XRecommends: unzip
END-of-zip.info
echo x - zip.patch
sed 's/^X//' zip.patch 'END-of-zip.patch'
Xdiff -Naur zip-2.3/unix/Makefile zip-new/unix/Makefile
X--- zip-2.3/unix/Makefile Sun Nov 28 21:22:42 1999
X+++ zip-new/unix/Makefile Thu May 16 21:19:17 2002
X@@ -47,7 +47,7 @@
X # LFLAGS2 flags after obj file list (libraries, etc)
X CFLAGS = -O2 -I. -DUNIX $(LOCAL_ZIP)
X LFLAGS1 =
X-LFLAGS2 = -s
X+LFLAGS2 =
X
X # object file lists
X OBJZ = zip.o zipfile.o zipup.o fileio.o util.o globals.o crypt.o ttyio.o \
Xdiff -Naur zip-2.3/unix/configure zip-new/unix/configure
X--- zip-2.3/unix/configure Tue Apr 27 12:49:05 1999
X+++ zip-new/unix/configure Thu May 16 21:42:46 2002
X@@ -13,7 +13,7 @@
X
X CC=${1-cc}
X CFLAGS=${2--O2 -I. -DUNIX}
X-LFLAGS1=-s
X+LFLAGS1=
X LN=ln -s
X
X echo Check for the C preprocessor
Xdiff -Naur zip-2.3/zip.c zip-new/zip.c
X--- zip-2.3/zip.c Tue Nov 16 12:08:10 1999
X+++ zip-new/zip.c Thu May 16 21:33:45 2002
X@@ -248,7 +248,7 @@
X if (PERR(c))
X perror(zip I/O error);
X fflush(mesg);
X-fprintf(stderr, \nzip error: %s (%s)\n, errors[c-1], h);
X+fprintf(stderr, \nzip error: %s (%s)\n, zip_errors[c-1], h);
X }
X if (tempzip != NULL)
X {
Xdiff -Naur zip-2.3/zipcloak.c zip-new/zipcloak.c
X--- zip-2.3/zipcloak.c Sun Nov 7 02:29:59 1999
X+++ zip-new/zipcloak.c Thu May 16 21:48:20 2002
X@@ -55,7 +55,7 @@
X char *msg; /* message about how it happened */
X {
X if (PERR(code)) perror(zipcloak error);
X-fprintf(stderr, zipcloak error: %s (%s)\n, errors[code-1], msg);
X+fprintf(stderr, zipcloak error: %s (%s)\n, zip_errors[code-1], msg);
X if (tempzf != NULL) fclose(tempzf);
X if (tempzip != NULL) {
X destroy(tempzip);
Xdiff -Naur zip-2.3/ziperr.h zip-new/ziperr.h
X--- zip-2.3/ziperr.h Sun Nov 7 02:31:27 1999
Re: [Fink-devel] Re: Idea: embed patch in .info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Macks wrote: A quick look at unstable/utils finds 20 or so packages where the .patch and .info have different rev's as a result of the -dev essentials fix, validator fixes, checksum additions, Source changes, typos. So one would have to bump the (CVS) rev of a corresponding .patch whenever this happens. All-told, about a third of the files there have rev1.1, meaning something has changed without bumping up %v-%r. Also is the case where some %v-%r use a patch and others don't (the OS X patches get rolled into the next %v, the maintainer learns some flag that makes hacking the source no-longer-necessary, etc.) If we want to keep CVS rev#s in sync, once a patch has existed for any %v-%r, it must exist for every future one. If a patch isn't required, a CVS committer must remember to look for one and commit a blank .patch in order to keep the CVS revisions in sync, and the trees get littered with blank files. And if a patch is required when upgrading a package, a CVS committer must check if there was one previously, otherwise he must force a CVS rev to correspond to the .info. This is all assuming that having the revisions match between the patch and the info file are important enough to make the committer go through the extra work to keep them in sync. I don't think it is, since it's easy enough to get it by date if you really need to know how they're paired up. Usually comments will be enough to figure out which is the relevant one. Okay, what if we tag .patch, and then change from having the .patch in the tree to being something that is downloaded during build? That way we get CVS history, don't have to go crazy keeping CVS rev#s in sync, and a given build process will always find the corresponding .patch? Would require a mightly reliable CVS server (but could run on a mirror if SF would enable such, or else seeding some other CVS server with the SF nightly tarball). I guess I'm confused what the problem being solved is... The original reason to switch to name.info and name.patch was to make it easier to find the history. That it does. Now it seems that because it's possible to look up history, we're ending up with proposals making things even harder than they already were for the most common every-day uses, by having new things you have to remember to do every time you make a change... I think it's overkill to have to remember to update a patch every time the info file is changed, or to pack/unpack shar archives to make a package... - -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ Just try to imagine a world where e-mails are sent by your brain before they are written, and are ready before they arrive by people you have never even met in countries you have never even heard of! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/D0VyUu+jZtP2Zf4RAvJyAKCchxk8hdVvNgTHY+lMPkrz5Z4j0QCeNza9 2oee8/2dRsiIHoZztrx0Wlw= =MreY -END PGP SIGNATURE- --- 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
[Fink-devel] Re: Idea: embed patch in .info
Add a new optional field Patch-MD5. If this field is present then refuse to use the .patch unless its md5sum matches. If the field isn't present then always use the provided .patch. This wouldn't help you match the .patch file to the .info file, but it would prevent problems like the one you encountered. -- K On Tue, 8 Jul 2003, Daniel Macks wrote: I've just had a problem arising from having plain-name .info and .patch files. In moving some files around while trying to find at which version/revision I introduced a bug, I managed to have the wrong (out-of-sync) .patch for the .info I was using. IIRC, this type of problem was mentioned (but not resolved?) when versionless naming was discussed (which I can't find in the -devel archives right now:(, as well as the related problem of trying to have multiple versions present by renaming the .info but then having to fix Patch: for a renamed .patch. So I was thinking about a solution based on placing the contents of the patch-file at the end of the .info file itself. One file, so no sync problems. The patch manpage claims that lines of junk (i.e., all the (other) .info fields) before the actual patch data are ignored, one could just feed the whole info-file to 'patch'. A new percent-variable could give the name of the info-file, so that other fields (Patch and PatchScript) will always find the (correct) patch-containing file, even if it gets renamed. So before I go about hacking fink to support this (doesn't look that difficult), anyone else think this would be a useful functionality? dan --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
not only a wait to combine them, but the seperate them too for when maintainers are making the next release. Sure. That's what I meant about needing tools. If we had a little tool for developers to use to bundle the .info and .patch file into a text archive (maybe with the shar format), and another tool to unbundle them again, we'd be in great shape. (Presumably fink would use the unbundling tool, too.) -- Dave --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
or we could gzip em and use zcat in fink :) On Thursday, July 10, 2003, at 01:36 PM, David R. Morrison wrote: Sure. That's what I meant about needing tools. If we had a little tool for developers to use to bundle the .info and .patch file into a text archive (maybe with the shar format), and another tool to unbundle them again, we'd be in great shape. (Presumably fink would use the unbundling tool, too.) --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
Well, it still doesn't solve the problem of how to retrieve an old patch file that correctly matches the fink version number. Peter O'Gorman jokingly suggested on IRC using ar to combine them. Or maybe it wasn't a joke? In fact, some way of combining them would be get. (The ar idea is not so good because the resulting file is binary; we need a text file so the CVS tracks revisions properly.) How about the ancient notion of a shar file. I haven't seen such a beast in a long time, nor tools to manipulate it, but it was basically a self-extracting, text-only version of a tar file. Is there an up to date version of this anyplace? -- Dave --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
not only a wait to combine them, but the seperate them too for when maintainers are making the next release. On Thursday, July 10, 2003, at 01:27 PM, David R. Morrison wrote: Peter O'Gorman jokingly suggested on IRC using ar to combine them. Or maybe it wasn't a joke? In fact, some way of combining them would be get. (The ar idea is not so good because the resulting file is binary; we need a text file so the CVS tracks revisions properly.) --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
Sounds good to me. My primary concern was the mismatch. Being able to easily find the correct .patch for a given .info (and handle multiple concurrent versions) would be nice, but by the time I'm messing around with multple versions I could just md5 until I find the right one at a time. dan TheSin said: : : this is much better idea. : : for devel we don't add the md5sum till we are done like the source md5 : and it solves mismatched info/patches : : On Thursday, July 10, 2003, at 12:39 PM, Kaben Nanlohy wrote: : : Add a new optional field Patch-MD5. If this field is present then : refuse to use the .patch unless its md5sum matches. If the field isn't : present then always use the provided .patch. : : This wouldn't help you match the .patch file to the .info file, but it : would prevent problems like the one you encountered. -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
Per-file cvs tags of .patch files. For foo.patch corresponding to foo.info with version 1.0 and revision 2: $ cvs checkout -r 1.0-2 foo.patch -- K On Thu, 10 Jul 2003, David R. Morrison wrote: Well, it still doesn't solve the problem of how to retrieve an old patch file that correctly matches the fink version number. Peter O'Gorman jokingly suggested on IRC using ar to combine them. Or maybe it wasn't a joke? In fact, some way of combining them would be get. (The ar idea is not so good because the resulting file is binary; we need a text file so the CVS tracks revisions properly.) How about the ancient notion of a shar file. I haven't seen such a beast in a long time, nor tools to manipulate it, but it was basically a self-extracting, text-only version of a tar file. Is there an up to date version of this anyplace? -- Dave --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kaben Nanlohy wrote: Per-file cvs tags of .patch files. For foo.patch corresponding to foo.info with version 1.0 and revision 2: $ cvs checkout -r 1.0-2 foo.patch If it's automated, maybe. Otherwise it kind of defeats the purpose of making things easy on the developer. =) Also, this doesn't cover making changes that don't require a revision bump... - -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ Odelay IS a word, just look it up in the Becktionary! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/DdkVUu+jZtP2Zf4RAgKfAJ4xoN+RAtkyE4qPugLES9Yk/A4abQCeIHyh OM4D297DXefHUMywT8fBR8M= =t3Op -END PGP SIGNATURE- --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
Benjamin Reed said: : Daniel Macks wrote: : : Patch-tracker #768801. : : Normally when I'm porting something, I'll put together a basic info : file, go to another window, build it, and wait for it to die. I go in, : make some changes, and generate a patch: : :diff -uNr foo-pristine foo /path/too/foo.patch : : Then I build again, and start over. If there's something wrong, I run : the diff again. : : If patches are embedded in the info file, every time I want to generate : a patch I need to delete the patch at the end of the info, close the : info file, generate the patch, and then re-edit the info file to make : other changes. No reason you can't still do this, and treat the embedding as a last- minute detail after the whole package is working and ready to go. Then just change %a to %A and stuff the .patch onto the end of .info. I agree that it makes generating the *next* revision an extra step or two (re-change %A-%a, rip off the old patch) unless you remembered to keep the parent file. : Not only that, but now we're relying on patch not accidentally thinking : anything in the info file is a directive to start a patch (I don't know : if it's been done, but I can imagine bits of diff being part of a : DescPort comment or something similar). My previous approach was to have the new percent-expand yield a shell command that would give the patch data on STDOUT, so then one could PatchScript: %[newthing] | patch -p1 and let fink snip off all of the .info before the stop-codon. But I didn't like having a weird new percent type (command vs. string) and in particular it would be less of a drop-in replacement for a .patch file. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- 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
Re: [Fink-devel] Re: Idea: embed patch in .info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Macks wrote: Patch-tracker #768801. Comments on either the idea or implementation? I'm not sure what I think. My problem with it is that it makes one of the most common development patterns more difficult. Normally when I'm porting something, I'll put together a basic info file, go to another window, build it, and wait for it to die. I go in, make some changes, and generate a patch: diff -uNr foo-pristine foo /path/too/foo.patch Then I build again, and start over. If there's something wrong, I run the diff again. If patches are embedded in the info file, every time I want to generate a patch I need to delete the patch at the end of the info, close the info file, generate the patch, and then re-edit the info file to make other changes. Not only that, but now we're relying on patch not accidentally thinking anything in the info file is a directive to start a patch (I don't know if it's been done, but I can imagine bits of diff being part of a DescPort comment or something similar). - -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ jbeimler yeah, rpm is for people who can't keep track of hundreds of scraps of paper -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/DYOaUu+jZtP2Zf4RAhHUAJ9vItsjAb7yNWeLIaNZWbxw4F2HewCgmuA9 6xBHdL2g4Uk8kQSpvypzils= =xZY0 -END PGP SIGNATURE- --- 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/bulletproofapps ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
