From: Chris S. <ir0...@gm...> - 2010-06-13 18:05:42
|
Hi All, I've built and packaged binutils-2.20.51 that has pseudo reloc V2 enabled by default (which is now the standard for MinGW targets). What I'm not sure of now what is the expected packaging breakdown? I currently have: binutils-2.20.51-1-mingw32-bin.tar.lzma - all the binaries, libraries, documentation, etc. binutils-2.20.51-1-mingw32-src.tar.lzma - the src package Do I need to create a manifest file for it as well? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2010-06-13 20:53:14
|
On Sunday 13 June 2010 19:05:35 Chris Sutcliffe wrote: > I've built and packaged binutils-2.20.51 ... Thanks, Chris. > What I'm not sure of now what is the expected packaging breakdown? > I currently have: > > binutils-2.20.51-1-mingw32-bin.tar.lzma - all the binaries, > libraries, documentation, etc. > binutils-2.20.51-1-mingw32-src.tar.lzma - the src package That'll do admirably. > Do I need to create a manifest file for it as well? I've already done that, for your previous releases; it's in the mingw-dist module, within our CVS repository on SF. It needs to be modified, to add the new release info, and then run through make, to convert it to the appropriate time-stamped lzma format, which is then uploaded to FRS, *overwriting* the existing file in the `catalogue' sub-directory for the mingw-get package. If you'd like to give it a go yourself, please do, but please be aware that the build infrastructure isn't fully established yet. If you'd rather I did it on this occasion, or if you need any further info, please let me know. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-06-14 02:29:56
|
Hi Keith, >> What I'm not sure of now what is the expected packaging breakdown? >> I currently have: >> >> binutils-2.20.51-1-mingw32-bin.tar.lzma - all the binaries, >> libraries, documentation, etc. >> binutils-2.20.51-1-mingw32-src.tar.lzma - the src package > > That'll do admirably. I've uploaded the files to SourceForge. >> Do I need to create a manifest file for it as well? > > I've already done that, for your previous releases; it's in the > mingw-dist module, within our CVS repository on SF. It needs to be > modified, to add the new release info, and then run through make, to > convert it to the appropriate time-stamped lzma format, which is then > uploaded to FRS, *overwriting* the existing file in the `catalogue' > sub-directory for the mingw-get package. > > If you'd like to give it a go yourself, please do, but please be aware > that the build infrastructure isn't fully established yet. If you'd > rather I did it on this occasion, or if you need any further info, > please let me know. I'm grabbing the mingw-dist module now to see what's involved. I'll let you know how I make out. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Chris S. <ir0...@gm...> - 2010-06-14 00:58:01
Attachments:
Makefile.sub
|
On 13 June 2010 20:29, Chris Sutcliffe wrote: >> If you'd like to give it a go yourself, please do, but please be aware >> that the build infrastructure isn't fully established yet. If you'd >> rather I did it on this occasion, or if you need any further info, >> please let me know. > > I'm grabbing the mingw-dist module now to see what's involved. I'll > let you know how I make out. Unfortunately I've hit a bit of a snag after trying to build the lzma after making changes to mingw32-binutils.xml. I executed 'autoconf' to generate 'configure' and then executed 'configure' to generate the Makefile. When executing 'make': ironhead@EUSH000065 /src/mingw-dist $ make make[1]: Entering directory `/src/mingw-dist/mingw32' ../Makefile.comm:48: Makefile.sub: No such file or directory echo 'auto-distfiles = \\' > Makefile.sub for file in mingw32-autoconf.xml mingw32-automake.xml mingw32-base.xml mingw32-basic-bsdtar.xml mingw32-binutils.xml mingw32-bzip2.xml mingw32-cygutils.xml mingw32-expat.xml mingw32-gdb.xml mingw32-gendef.xml mingw32-gettext.xml mingw32-gmp.xml mingw32-libarchive.xml mingw32-libiconv.xml mingw32-libtool.xml mingw32-make.xml mingw32-mingw-utils.xml mingw32-pexports.xml mingw32-popt.xml mingw32-runtime.xml mingw32-xz.xml mingw32-zlib.xml; do echo "$file.lzma \\" | sed 's,.*/, ,' >> Makefile.sub; done echo ' $(EXTRA_DISTFILES)' >> Makefile.sub make[1]: Leaving directory `/src/mingw-dist/mingw32' make[1]: Entering directory `/src/mingw-dist/mingw32' Makefile.sub:2: *** missing separator. Stop. make[1]: Leaving directory `/src/mingw-dist/mingw32' make: *** [mingw32] Error 2 I've attached Makefile.sub for your reference (looks fine to me). Did I miss something? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Greg C. <gch...@sb...> - 2010-06-14 10:06:01
|
On 2010-06-14 00:57Z, Chris Sutcliffe wrote: > > ironhead@EUSH000065 /src/mingw-dist > $ make > make[1]: Entering directory `/src/mingw-dist/mingw32' > ../Makefile.comm:48: Makefile.sub: No such file or directory > echo 'auto-distfiles = \\' > Makefile.sub Examining the raw message, I see: echo 'auto-distfiles =3D \\' > Makefile.sub and I guess "=3D" is an email-escaped equals-sign (but I think that's not the problem). It's quickly followed by "\\", which I guess is intended to be an escaped single backslash, but it produces a double backslash when I look at your attached 'Makefile.sub'. Here it is, viewed through 'od -t a': 0000000 a u t o - d i s t f i l e s sp = 0000020 sp \ \ nl m i n g w 3 2 - a u t o 0000040 c o n f . x m l . l z m a sp \ nl 0000060 m i n g w 3 2 - a u t o m a k e 0000100 . x m l . l z m a sp \ nl m i n g > for file in mingw32-autoconf.xml mingw32-automake.xml mingw32-base.xml [...snip some files...] > mingw32-popt.xml mingw32-runtime.xml mingw32-xz.xml mingw32-zlib.xml; > do echo "$file.lzma \\" | sed 's,.*/, ,' >> Makefile.sub; done Those lines, OTOH, end in single backslashes. What they echo is written in double quotes. Should the first line be changed to use double quotes as well? I.e.: - echo 'auto-distfiles = \\' > Makefile.sub + echo "auto-distfiles = \\" > Makefile.sub > Makefile.sub:2: *** missing separator. Stop. I think that's caused by the doubled backslash on the first line: auto-distfiles = \\ mingw32-autoconf.xml.lzma \ |
From: Keith M. <kei...@us...> - 2010-06-14 21:03:41
|
On Monday 14 June 2010 01:57:54 Chris Sutcliffe wrote: > > I'm grabbing the mingw-dist module now to see what's involved. > > I'll let you know how I make out. > Unfortunately I've hit a bit of a snag after trying to build the > lzma after making changes to mingw32-binutils.xml. Okay, you've hit the first of *two* snags, both of which originate in Makefile.comm.in; the one you haven't discovered yet is that there is a reference to $(serial_number) which should be to $(issue_number); for the one you did encounter... > I executed > 'autoconf' to generate 'configure' and then executed 'configure' to > generate the Makefile. So far, so good, (although I would VERY STRONGLY recommend that you DO NOT run configure or make in the source directory -- you are likely to end up with a lot of noise, when you come to commit changes to CVS). > When executing 'make': > > ironhead@EUSH000065 /src/mingw-dist > $ make > make[1]: Entering directory `/src/mingw-dist/mingw32' > ../Makefile.comm:48: Makefile.sub: No such file or directory Still good to here. > echo 'auto-distfiles = \\' > Makefile.sub > for file in mingw32-autoconf.xml mingw32-automake.xml > ... > do echo "$file.lzma \\" | sed 's,.*/, ,' >> Makefile.sub; done But now, it has gone wrong. > echo ' $(EXTRA_DISTFILES)' >> Makefile.sub > make[1]: Leaving directory `/src/mingw-dist/mingw32' > make[1]: Entering directory `/src/mingw-dist/mingw32' > Makefile.sub:2: *** missing separator. Stop. > make[1]: Leaving directory `/src/mingw-dist/mingw32' > make: *** [mingw32] Error 2 > > I've attached Makefile.sub for your reference (looks fine to me). It *doesn't* look fine to me; on the first line I see auto-distfiles = \\ where it should be auto-distfiles = \ (i.e. there's one too many escapes for the newline). > Did I miss something? No, (other than overlooking the extraneous backslash). The problem is in Makefile.comm (generated from Makefile.comm.in): Makefile.sub: ${srcdir}/*.xml echo 'auto-distfiles = \\' > $@ ... On my Ubuntu box, GNU make-3.81 reduces that doubled backslash to a single escape; with MSYS it doesn't! I suspect that the bug may be the result of a quirk in Ubuntu's /bin/sh implementation (which is a symlink to dash), because if I rewrite the rule (correctly) as Makefile.sub: ${srcdir}/*.xml echo 'auto-distfiles = \' > $@ ... or (equally correctly) as Makefile.sub: ${srcdir}/*.xml echo "auto-distfiles = \\" > $@ ... I get the intended behaviour in both cases, (MSYS and Ubuntu). Also, on the Ubuntu box, if I execute either of the commands $ echo 'auto-distfiles = \' $ echo 'auto-distfiles = \\' from a /bin/sh command prompt, I get the desired auto-distfiles = \ but from a /bin/bash prompt, only the former emits the desired output, while the latter emits (as on MSYS) auto-distfiles = \\ The solution is either to remove the extraneous backslash from Makefile.comm.in, or to change the single quotes to double, in the offending command[*], then blow away the offending Makefile.sub, run config.status to regenerate the Makefiles, and run make again. [*] The latter change may be the better choice; it is less likely to trip over the shell portability issue, should some other shell ever come into play. I'll commit an appropriate correction, for *both* problems, within the next day or two. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-06-15 02:01:20
|
On 14 June 2010 08:36, Keith Marshall wrote: > The solution is either to remove the extraneous backslash from > Makefile.comm.in, or to change the single quotes to double, in the > offending command[*], then blow away the offending Makefile.sub, run > config.status to regenerate the Makefiles, and run make again. I've created the mingw32-binutils.xml.lzma archive but I don't see a 'catalogue' subdirectory under the mingw-get package. Where do I commit the new file? Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2010-06-15 19:02:43
|
On Tuesday 15 June 2010 02:31:07 Chris Sutcliffe wrote: > I've created the mingw32-binutils.xml.lzma archive but I don't see > a 'catalogue' subdirectory under the mingw-get package. Where are you looking? > Where do I commit the new file? Before you do, please verify that the issue number has been properly assigned; (if you corrected the $(serial_number) vs. $(issue_number) conflict in Makefile.comm, it should have been): $ lzma -dc mingw32-binutils.xml.lzma | sed 2q If you see `issue="@YYYYMMDDNN@"' near the end of the second line, then there is a problem, and you must not upload the file. Provided you see `issue="2010061500"' (or a similar number), then you may upload to FRS, using the SF file manager: https://sourceforge.net/project/admin/explorer.php?group_id=2435 Navigate to: /Automated MinGW Installer/mingw-get/catalogue/ Upload here: mingw32-binutils.xml.lzma or by SFTP[*]: $ sftp yourname,mi...@fr... sftp> cd /home/frs/project/m/mi/mingw sftp> cd Automated\ MinGW\ Installer/mingw-get/catalogue sftp> put mingw32-binutils.xml.lzma Note that, whichever your preferred upload mechanism, the target file will already exist; you *must* overwrite it, because mingw-get will not fetch it if you use a different (e.g. versioned) name. [*] I'm offline as I type this; I hope I've recalled the details correctly. (We should rename that directory, omitting spaces and, since it's no longer MinGW specific, maybe shorten it to something like `AutomaticInstallers'; WDYT?). -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-06-16 01:26:04
|
On 15 June 2010 04:55, Keith Marshall wrote: > On Tuesday 15 June 2010 02:31:07 Chris Sutcliffe wrote: >> I've created the mingw32-binutils.xml.lzma archive but I don't see >> a 'catalogue' subdirectory under the mingw-get package. > > Where are you looking? My mistake, I had assumed the 'catalogue' directory was under the mingw-get CVS repository. >> Where do I commit the new file? > > Before you do, please verify that the issue number has been properly > assigned; (if you corrected the $(serial_number) vs. $(issue_number) > conflict in Makefile.comm, it should have been): > > $ lzma -dc mingw32-binutils.xml.lzma | sed 2q I've updated my local repository with your committed changes, so it all looks good. > If you see `issue="@YYYYMMDDNN@"' near the end of the second line, > then there is a problem, and you must not upload the file. Provided > you see `issue="2010061500"' (or a similar number), then you may > upload to FRS, using the SF file manager: > > https://sourceforge.net/project/admin/explorer.php?group_id=2435 > Navigate to: /Automated MinGW Installer/mingw-get/catalogue/ > Upload here: mingw32-binutils.xml.lzma Done. > Note that, whichever your preferred upload mechanism, the target file > will already exist; you *must* overwrite it, because mingw-get will > not fetch it if you use a different (e.g. versioned) name. Understood, it looks like the FRS web mechanism overwrote the existing file (judging by timestamp). Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2010-06-17 17:11:21
|
On Wednesday 16 June 2010 02:25:55 Chris Sutcliffe wrote: > > upload to FRS, using the SF file manager: > > > > https://sourceforge.net/project/admin/explorer.php?group_id=2435 > > Navigate to: /Automated MinGW Installer/mingw-get/catalogue/ > > Upload here: mingw32-binutils.xml.lzma > > Done. Thanks. Could you commit your modified mingw32-binutils.xml back into CVS please? > > Note that, whichever your preferred upload mechanism, the target > > file will already exist; you *must* overwrite it, because > > mingw-get will not fetch it if you use a different (e.g. > > versioned) name. > > Understood, it looks like the FRS web mechanism overwrote the > existing file (judging by timestamp). Excellent. Later tonight, if I can find a round tuit, I'll try: $ ./mingw-get.exe update $ ./mingw-get.exe upgrade mingw32-binutils with my Wine hosted debug build of mingw-get, to check that it's doing the right thing. I'll report back. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-06-17 23:01:23
|
On 17 June 2010 11:46, Keith Marshall wrote: > On Wednesday 16 June 2010 02:25:55 Chris Sutcliffe wrote: >> > upload to FRS, using the SF file manager: >> > >> > https://sourceforge.net/project/admin/explorer.php?group_id=2435 >> > Navigate to: /Automated MinGW Installer/mingw-get/catalogue/ >> > Upload here: mingw32-binutils.xml.lzma >> >> Done. > > Thanks. Could you commit your modified mingw32-binutils.xml back into > CVS please? Sorry, forgot to do that. I've committed it now. I assume the updated issue.log files should not be committed? > Excellent. Later tonight, if I can find a round tuit, I'll try: > > $ ./mingw-get.exe update > $ ./mingw-get.exe upgrade mingw32-binutils > > with my Wine hosted debug build of mingw-get, to check that it's doing > the right thing. I'll report back. Excellent! Is there an updated mingw-get to test yet, or is alpha-1 still the one to test? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2010-06-18 23:08:40
|
On Friday 18 June 2010 00:01:14 Chris Sutcliffe wrote: > On 17 June 2010 11:46, Keith Marshall wrote: > > On Wednesday 16 June 2010 02:25:55 Chris Sutcliffe wrote: > >> > upload to FRS, using the SF file manager: > >> > > >> > https://sourceforge.net/project/admin/explorer.php?group_id=2 > >> >435 Navigate to: /Automated MinGW > >> > Installer/mingw-get/catalogue/ Upload here: > >> > mingw32-binutils.xml.lzma > >> > >> Done. > > > > Thanks. Could you commit your modified mingw32-binutils.xml back > > into CVS please? > > Sorry, forgot to do that. I've committed it now. Thanks. > I assume the updated issue.log files should not be committed? For the time being, no. Ultimately, they will need to be, but I'll fix them up appropriately when I've got the build system ready to handle them correctly. > > Excellent. Later tonight, if I can find a round tuit, I'll try: > > > > $ ./mingw-get.exe update > > $ ./mingw-get.exe upgrade mingw32-binutils > > > > with my Wine hosted debug build of mingw-get, to check that it's > > doing the right thing. I'll report back. Didn't get to that last night. I have now, and it looks good. One which doesn't look good though: I just pushed the manifest for mingw32-make, (so we're now covering all of MinGW-5.1.6's payload, plus gdb and expat-dll), and while testing, I notice that it will overwrite share/info/dir. This is just so wrong; please repackage it, omitting that file. > Excellent! Is there an updated mingw-get to test yet, or is > alpha-1 still the one to test? alpha-2 was published on 17-May; that's the current version. alpha-1 will not process the current multi-file manifests; you should upgrade. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-06-19 03:41:18
|
On 18 June 2010 19:07, Keith Marshall wrote: > Didn't get to that last night. I have now, and it looks good. One > which doesn't look good though: I just pushed the manifest for > mingw32-make, (so we're now covering all of MinGW-5.1.6's payload, > plus gdb and expat-dll), and while testing, I notice that it will > overwrite share/info/dir. This is just so wrong; please repackage > it, omitting that file. I've taken it one step further and grabbed the latest make CVS which has an additional Windows specific fix from Eli. From a packaging aspect, I have the following: make-3.81.90-20100618-1-mingw32-src.tar.lzma make-3.81.90-20100618-1-mingw32-bin.tar.lzma Is the date and a release number in the filename going to cause issues? Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-06-19 05:14:57
|
On 6/18/2010 11:41 PM, Chris Sutcliffe wrote: > I've taken it one step further and grabbed the latest make CVS which > has an additional Windows specific fix from Eli. From a packaging > aspect, I have the following: > > make-3.81.90-20100618-1-mingw32-src.tar.lzma > make-3.81.90-20100618-1-mingw32-bin.tar.lzma > > Is the date and a release number in the filename going to cause issues? Well, that parses as: Package Name: make Package Version: 3.81.90 Package Build: 20100618-1 Subsystem Name: mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Release Status: <unspecified> Release Reference: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type lzma I usually interpret the package version to mean "the upstream source version" -- so you probably want "3.81.90_20100618" (with an underscore) instead. That way the Package Build is "1". -- Chuck > |
From: Keith M. <kei...@us...> - 2010-06-19 09:35:25
|
On Saturday 19 June 2010 06:14:28 Charles Wilson wrote: > > I've taken it one step further and grabbed the latest make CVS > > which has an additional Windows specific fix from Eli. From a > > packaging aspect, I have the following: > > > > make-3.81.90-20100618-1-mingw32-src.tar.lzma > > make-3.81.90-20100618-1-mingw32-bin.tar.lzma > > > > Is the date and a release number in the filename going to cause > > issues? > > ... > > I usually interpret the package version to mean "the upstream > source version" -- so you probably want "3.81.90_20100618" (with an > underscore) instead. That way the Package Build is "1". From mingw-get's perspective, either is acceptable, (or should be). From a stylistic perspective, I personally prefer the form Chris has proposed. Pragmatically, if it represents a formal snapshot released on yesterday's date, BY THE UPSTREAM PROJECT, then I can accept an argument in favour of Chuck's style; if, (as I understand it), it is simply Chris' own informal ad-hoc snapshot, built from upstream CVS HEAD, then perhaps Chris' naming style is to be preferred. Just my immediate thoughts on the matter; perhaps, for sake of future consistency, we should formalise it? -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-06-19 12:07:31
|
On 19 June 2010 05:35, Keith Marshall wrote: > On Saturday 19 June 2010 06:14:28 Charles Wilson wrote: >> > I've taken it one step further and grabbed the latest make CVS >> > which has an additional Windows specific fix from Eli. From a >> > packaging aspect, I have the following: >> > >> > make-3.81.90-20100618-1-mingw32-src.tar.lzma >> > make-3.81.90-20100618-1-mingw32-bin.tar.lzma >> > >> > Is the date and a release number in the filename going to cause >> > issues? >> >> ... >> >> I usually interpret the package version to mean "the upstream >> source version" -- so you probably want "3.81.90_20100618" (with an >> underscore) instead. That way the Package Build is "1". > > >From mingw-get's perspective, either is acceptable, (or should be). > From a stylistic perspective, I personally prefer the form Chris has > proposed. Pragmatically, if it represents a formal snapshot released > on yesterday's date, BY THE UPSTREAM PROJECT, then I can accept an > argument in favour of Chuck's style; if, (as I understand it), it is > simply Chris' own informal ad-hoc snapshot, built from upstream CVS > HEAD, then perhaps Chris' naming style is to be preferred. I prefer the way it would be parsed as it stands: Package Build: 20100618-1 As Keith pointed out, this is an unofficial snapshot from CVS that I pulled to capture an additional fix from Eli. > Just my immediate thoughts on the matter; perhaps, for sake of future > consistency, we should formalise it? Agreed, it will ease confusion going forward. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-06-19 12:46:03
|
On 6/19/2010 8:07 AM, Chris Sutcliffe wrote: > On 19 June 2010 05:35, Keith Marshall wrote: >> Just my immediate thoughts on the matter; perhaps, for sake of future >> consistency, we should formalise it? > > Agreed, it will ease confusion going forward. I won't object. By formalize, do you mean to document it in http://www.mingw.org/PackageIdentificationHOWTO and also in the pkginfo.l comments? Do you want to take care of that, Keith? There aren't many packages at present that follow any such rule; most MSYS packages are based on official upstream snaps (*). And of those few, they don't all follow any consistent rule anyway. :-( xz-4.999.9beta_20100401-1-msys-1.0.13-bin.tar.gz xz-4.999.8beta_20090725git-1-msys-1.0.11-bin.tar.gz diffutils-2.8.7.20071206cvs-3-msys-1.0.13-bin.tar.lzma (*) By "upstream snap" I also include those packages that are based directly on cygwin packages. For instance, our perl packages are based on the cygwin perl-5.6.1-2-src.tar.bz2 package, so OURS are named perl-5.6.1_2-2-msys-1.0.13-bin.tar.lzma ^^^^^^^ cygwin version Similarly, cygwin: termcap-20050421-1-src.tar.bz2 msys: termcap-0.20050421_1-2-msys-1.0.13-bin.tar.lzma ^^^^^^^^^^ cygwin version The "0." was necessary to convince pkginfo.l to parse the first field as Package Version, rather than Package Name "termcap-20050421_1" and Version "2" with no Build. -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-06-19 19:33:40
|
On 19 June 2010 08:07, Chris Sutcliffe wrote: > I prefer the way it would be parsed as it stands: > > Package Build: 20100618-1 How will mingw-get treat this? Does it use Package Build as a number to determine the most recent? If thats the case, will 20100618-1 be treated as 20100617 (i.e. 20100618 minus 1) and 20100618-2 would be treated as 20100616 (i.e. 20100618 minus 2)? This would result in potentially the wrong file being grabbed. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2010-06-19 20:57:55
|
On Saturday 19 June 2010 20:33:33 Chris Sutcliffe wrote: > On 19 June 2010 08:07, Chris Sutcliffe wrote: > > I prefer the way it would be parsed as it stands: > > > > Package Build: 20100618-1 > > How will mingw-get treat this? Does it use Package Build as a > number to determine the most recent? If thats the case, will > 20100618-1 be treated as 20100617 (i.e. 20100618 minus 1) and > 20100618-2 would be treated as 20100616 (i.e. 20100618 minus 2)? > This would result in potentially the wrong file being grabbed. It will treat it exactly as you want: as the first release of build number 20100618. The hyphens are parsed as field separators, not as mathematical symbols. The package version number and build number are decomposed into a sequence of fields, separated by periods and hyphens, then the corresponding fields of each of two releases are compared left to right; the numerically greater of the first pair to differ is taken as representing the most recent release. Thus, 20100618-1 < 20100618-2, and the latter is taken as most recent. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-06-21 11:50:13
|
On 19 June 2010 16:57, Keith Marshall wrote: > On Saturday 19 June 2010 20:33:33 Chris Sutcliffe wrote: >> How will mingw-get treat this? Does it use Package Build as a >> number to determine the most recent? If thats the case, will >> 20100618-1 be treated as 20100617 (i.e. 20100618 minus 1) and >> 20100618-2 would be treated as 20100616 (i.e. 20100618 minus 2)? >> This would result in potentially the wrong file being grabbed. > > It will treat it exactly as you want: as the first release of build > number 20100618. The hyphens are parsed as field separators, not as > mathematical symbols. The package version number and build number > are decomposed into a sequence of fields, separated by periods and > hyphens, then the corresponding fields of each of two releases are > compared left to right; the numerically greater of the first pair to > differ is taken as representing the most recent release. > > Thus, 20100618-1 < 20100618-2, and the latter is taken as most recent. Excellent, thank you for confirming. Is there any decision on this then? Am I OK to upload the new files and update mingw32-make.xml accordingly? Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2010-06-28 20:08:44
|
On Monday 21 June 2010 12:50:03 Chris Sutcliffe wrote: > Am I OK to upload the new files and update mingw32-make.xml > accordingly? Please do. -- Regards, Keith. |