From: Keith M. <kei...@us...> - 2008-03-29 17:54:30
|
On Saturday 29 March 2008 15:43, NightStrike wrote: > On 3/29/08, Keith Marshall <kei...@us...> wrote: > > On Wednesday 26 March 2008 18:06, Earnie Boyd wrote: > > > x86_64-pc-mingw32 of course is meaningless. > > > > Actually, it is just a standard 32-bit MinGW (Win32), running on a > > 64-bit host; it does have meaning, but it isn't what NightStrike > > wants to make it... > > > > > x86_64-pc-mingw64 is what it should be. > > > > This, of course, is what he really wants, for a 64-bit MinGW. > > What do you mean by that? Simply that x86_64-pc-mingw32 isn't devoid of meaning, as Earnie suggests; it explicitly identifies a system with Win32 code, running on a 64-bit processor. Just as many of us ran 16-bit code on 32-bit processors, for many years, this is a perfectly viable configuration. However, it isn't the configuration which you are seeking to describe; for your system, the appropriate *canonical* description is x86_64-pc-mingw64, (or equally appropriately, x86_64-unknown-mingw64), and mingw64 alone is unambigously sufficient to identify that, albeit non-canonically. Regards, Keith. |
From: Charles W. <cwi...@us...> - 2008-03-29 18:27:04
|
Keith Marshall wrote: > Semantically, it makes no difference. Syntactically, I think it is > easier to read, (by humans), if the dll version is also preceded by a > hyphen, (it makes the `dll' element stand out better), so the last > would become: > > mingw-runtime-3.14-1-dll-0.tar.gz True, but that makes it much harder for automatic parsing (thinking of dependency/package management software). "The last chunk is part of the package 'name'" vs. "The last chunk, or maybe the last two chunks if the N-1 chunk == 'dll' is part of the package 'name'". Take a look at today's version of this page: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879&release_id=540763 Look at the (new) guile or openssl packages... -- Chuck |
From: Keith M. <kei...@us...> - 2008-03-31 16:58:14
|
On Saturday 29 March 2008 18:25, Charles Wilson wrote: > > Semantically, it makes no difference. Syntactically, I think it is > > easier to read, (by humans), if the dll version is also preceded by > > a hyphen, (it makes the `dll' element stand out better), so the > > last would become: > > > > mingw-runtime-3.14-1-dll-0.tar.gz > > True, but that makes it much harder for automatic parsing (thinking > of dependency/package management software). "The last chunk is part > of the package 'name'" vs. "The last chunk, or maybe the last two > chunks if the N-1 chunk == 'dll' is part of the package 'name'". I'm having a hard time convincing myself why this should be so. Conversion from either form to the other is trivial, (even treating the name case-insensitively), using regular expressions:-- $ echo mingw-runtime-3.14-1-dll-0.tar.gz | sed 's/-\([Dd][Ll][Ll]\)-/-\1/' mingw-runtime-3.14-1-dll0.tar.gz $ echo mingw-runtime-3.14-1-dll0.tar.gz | sed 's/-\([Dd][Ll][Ll]\)\([^-.]\)/-\1-\2/' mingw-runtime-3.14-1-dll-0.tar.gz > Take a look at today's version of this page: > \ http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879&release_id=540763 > > Look at the (new) guile or openssl packages... I did, and I have some concerns about the names. However, since I am on holiday for the next two weeks, starting tonight, I'd prefer to address them on my return. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-04-21 23:46:14
|
On Monday 31 March 2008 17:57, Keith Marshall wrote: > > Look at the (new) guile or openssl packages... > > I did, and I have some concerns about the names. Ok. There's nothing particularly earth shattering. Suppose we view the package naming convention in terms of the schema:-- <archive-name> ::= <pkg-id>["-"<subsystem-id>]"-"<type-id> <pkg-id> ::= <pkg-name>"-"<version>["-"<build-id>] <subsystem-id> ::= <subsystem-name>["-"<version>]["-"<build-id>] <type-id> ::= <component-id>"."<format-type>["."<compression-type>] <version> ::= <major>["."<minor>["."<patchlevel>]] <build-id> ::= <datestamp>["-"<serial-number>] | <serial-number> <component-id> ::= <component-class>["-"<version>] <component-class> ::= "bin" | "dev" | "dll" | "src" | "mingwPORT" <format-type> ::= "tar" | "exe" | "zip" <compression-type> ::= "gz" | "bz2" | ... Now, for example, you have `guile-1.8.4-MSYS-1.0.11-1-dll17.tar.gz', which in terms of the schema, gives us:-- Package Name: guile Package Version: 1.8.4 (major = 1; minor = 8; patchlevel = 4) Package Build: unspecified Subsystem Name: MSYS Subsystem Version: 1.0.11 (major = 1; minor = 0; patchlevel = 11) Subsystem Build: 1 (datestamp unspecified; serial no = 1) Component Class: dll Component Version: 17 (assuming implicit separator => dll-17) Archive Format: tar Compression Type: gz Aside from the issue of the omitted separator in `dll-17', which we've noted before, and have yet to agree formally on its advisability, my one other minor concern is with the placement of the build serial number; don't you mean this to refer to the package build rather than to the subsystem build, and would it not therefore be more logical to place it after the package version number? Thus, we would have an overall archive name of `guile-1.8.4-1-MSYS-1.0.11-dll-17.tar.gz'. As I say, this is a minor issue, and certainly not worth a fresh upload for no other reason than to change it, but I would like us to agree on a consistent standard for naming of future packages. Regards, Keith. |
From: Charles W. <cwi...@us...> - 2008-04-22 01:07:45
|
Keith Marshall wrote: > Ok. There's nothing particularly earth shattering. Suppose we view the > package naming convention in terms of the schema:-- > > <archive-name> ::= <pkg-id>["-"<subsystem-id>]"-"<type-id> > <pkg-id> ::= <pkg-name>"-"<version>["-"<build-id>] > <subsystem-id> ::= <subsystem-name>["-"<version>]["-"<build-id>] > <type-id> ::= <component-id>"."<format-type>["."<compression-type>] > <version> ::= <major>["."<minor>["."<patchlevel>]] > <build-id> ::= <datestamp>["-"<serial-number>] | <serial-number> > <component-id> ::= <component-class>["-"<version>] > <component-class> ::= "bin" | "dev" | "dll" | "src" | "mingwPORT" > <format-type> ::= "tar" | "exe" | "zip" > <compression-type> ::= "gz" | "bz2" | ... > > Now, for example, you have `guile-1.8.4-MSYS-1.0.11-1-dll17.tar.gz', > which in terms of the schema, gives us:-- > > Package Name: guile > Package Version: 1.8.4 (major = 1; minor = 8; patchlevel = 4) > Package Build: unspecified > > Subsystem Name: MSYS > Subsystem Version: 1.0.11 (major = 1; minor = 0; patchlevel = 11) > Subsystem Build: 1 (datestamp unspecified; serial no = 1) > > Component Class: dll > Component Version: 17 (assuming implicit separator => dll-17) > > Archive Format: tar > Compression Type: gz > > Aside from the issue of the omitted separator in `dll-17', which we've > noted before, and have yet to agree formally on its advisability, I drop any objections to the '-' between ComponentClass and ComponentVersion. The only problem I have with the specified schema is that I *think* it is not possible for a non-human to parse it unambiguously if there are missing fields. I don't know if that is important. It may be, if you want automated package/dependency management. However, we are not required to infer this information from the package names. You could instead have your package manager use ancillary files (like cygwin's setup.exe's setup.hint/setup.ini, only with a few more fields). e.g. guile.setup.hint package: guile-1.8.4-1-MSYS-1.0.11-1-dll-17.tar.gz version|subsys: 1.8.4-1|MSYS-1.0.11-1 (other setup.hint fields) package: guile-1.8.4-2-MSYS-1.0.11-1-dll-17.tar.gz version|subsys: 1.8.4-2|MSYS-1.0.11-1 (other setup.hint fields, specific to this version of guile*dll-17) The individualized pieces specified in the version|subsys key are unambiguously parseable, with the following change: <build-id> ::= <datestamp>"-"<serial-number> | <serial-number> That is, if you have <datestamp>, you *must* have <serial-number>. That way, taking either the version half of the version|subsys key, or the subsys half, if there are four '-' separated fields, then #3 is <datestamp> and #4 is <serial-number>. If there are only three fields, then #3 is <serial-number>. Yes, it's a little redundant to have both the package: key and the version|subsys: key, but any "error-correction" scheme requires redundancy, and that's what we're trying to do here: correct errors in the automated tarball name <-> schema parser. (actually, following cygwin setup's lead, you don't really need the package: key -- you can get that from the filesystem, and match the version|subsys strings to pair them up. That's what the genini perl script that runs on sources.redhat.com does.) > my > one other minor concern is with the placement of the build serial > number; don't you mean this to refer to the package build rather than > to the subsystem build, and would it not therefore be more logical to > place it after the package version number? Thus, we would have an > overall archive name of `guile-1.8.4-1-MSYS-1.0.11-dll-17.tar.gz'. Sure, if you allowed the subsystem to have a release number. My grouping was: (guile-1.8.4)-(MSYS-1.0.11)-1-(dll[-]17) where the release number 'versioned' the entire string: guile-1.8.4-MSYS-1.0.11. But your way is fine, too. > As I say, this is a minor issue, and certainly not worth a fresh upload > for no other reason than to change it, but I would like us to agree on > a consistent standard for naming of future packages. Absolutely, Frankly, I don't much care what the naming convention is, as long as it is rational and not drempt up by Picasso on crack. We should just pick one, and stick with it unless there is a very good technical reason to change it. -- Chuck |
From: Charles W. <cwi...@us...> - 2008-04-22 01:48:15
|
Keith Marshall wrote: > On Friday 28 March 2008 05:54, Charles Wilson wrote: >> FWIW, here's the difference in size for vim, between >> >> (1) bzip2, allow hardlinks in the archive and >> (2) gzip, hardlinks replaced by actual copies >> >> vim-7.1-MSYS-1.0.11-1-bin.tar.bz2 6902551 >> vim-7.1-MSYS-1.0.11-1-bin.tar.gz 15021027 >> >> That is, the "new standard" version is more than twice the size of >> the old version. This, to me, is not an improvement. > > No, it certainly isn't! I'd guess that most of the "inflation" results > from the dereferencing of hard links at package build time, rather than > the different compression standard. Mostly, yes. hardlinks copies vim-7.1-MSYS-1.0.11-1-bin.tar.bz2 6 902 551 13 521 217 vim-7.1-MSYS-1.0.11-1-bin.tar.gz 8 097 226 15 021 027 vim-7.1-MSYS-1.0.11-1-bin.tar.lzma 5 094 643 5 096 541 Note that lzma almost completely eliminates the redundancy. I didn't expect that. 'Course, no "normal" native windows tool supports lzma, so we'd have to build support for that into (a) our installer, (b) and provide a native 'mingw' version of tar + lzma, for bootstrapping commandline junkies like me. (b) is not hard; we can leverage the old gnuwin32 gnutar (not their present bsdtar), and lzma actually ships a native win32 binary in the source archive. (a) might be harder: lzma decomp is available as a library (actually you just included six or so specific files into your build, it's not distributed as a "library" per se), but I don't know how the current installer achieves its "archive unpacking" functionality. I know that in cygwin setup.exe, you'd just need to write a single derived class that encapsulates the interface to the compression library... However, the advantage would be that we could (a) avoid hardlinks in the tarballs with no size penalty, (b) not have to worry if the mingw tar supported extracting hardlinks properly, by requiring packagers use the --hard-dereference option in tar-1.19.90 when creating packages, and (c) we would *guarantee* that nobody would try to use WinZip to unpack the archive, with its notorious "Smart [that is, extremely dumb] CR/LF conversion" switch. Which is turned on, by default. > I'm tempted to suggest that requiring MSYS tools for unpacking *MSYS* > add-on packages may not be unreasonable; with that stipulation, there > really does seem little reason to prefer .gz over .bz2, (except in > those few cases where gzip actually achieves *better* compression; they > may be rare, but there are a few). In this scenario, I'd definitely prefer lzma -- but I don't think that's one of the file-type choices on SourceForge (except "Other Binary Package" and "Other Source File") > However, we have seen evidence on the MSYS list, where more than one > user has broken his MSYS installation by using some other archiving > tool, and so getting tools installed in a /usr hierarchy which becomes > occluded by the MSYS loopback mount of /usr on /. (It was this which > prompted my escalation of Earnie's original request to repackage the > tarballs relative to /, rather than to /usr; that may have been > something of an exercise in futility, if we do stipulate that only MSYS > tar is supported for unpacking). Unless, as somebody suggested earlier -- and I mention above -- we provide *mingw* command line tools specifically for unpacking these archives. Those tools would not understand the msys mount system. (Also, it might simplify the installer code if it didn't have to worry about intercepting file names when unpacking). So, the repackaging form /usr -> / *had* to be done. I'm just miffed at having to do it *again* for naming/compression format reasons. If I'm going to do THAT, let's at least keep it down to *one* more re-spin, not two. -- Chuck |
From: Greg C. <gch...@sb...> - 2008-04-22 04:20:41
|
On 2008-04-22 01:48Z, Charles Wilson wrote: [...] > 'Course, no "normal" native windows tool supports lzma, so we'd have to > build support for that into (a) our installer, (b) and provide a native > 'mingw' version of tar + lzma, for bootstrapping commandline junkies > like me. > > (b) is not hard; we can leverage the old gnuwin32 gnutar (not their > present bsdtar), and lzma actually ships a native win32 binary in the > source archive. gnuwin32 gnutar has dependencies on two dlls that it provides: $cygcheck c:/Program\ Files/GnuWin32/bin/tar.exe |sed -e'/WINDOWS/d' c:/Program Files/GnuWin32/bin/tar.exe c:/Program Files/GnuWin32/bin\libintl-2.dll c:/Program Files/GnuWin32/bin\libiconv-2.dll I wonder whether those dlls would conflict with other versions that a user might have installed? I keep trying to get the source in order to see whether it can be built without those dependencies, but the sourceforge download site is unusually unresponsive tonight. > (a) might be harder: lzma decomp is available as a library (actually you > just included six or so specific files into your build, it's not > distributed as a "library" per se), but I don't know how the current > installer achieves its "archive unpacking" functionality. I know that in > cygwin setup.exe, you'd just need to write a single derived class that > encapsulates the interface to the compression library... The current installer seems to be NSIS, whose documentation says it supports lzma: http://nsis.sourceforge.net/Features | three different integrated compression methods (ZLib, BZip2, LZMA) > However, the advantage would be that we could (a) avoid hardlinks in the > tarballs with no size penalty, (b) not have to worry if the mingw tar > supported extracting hardlinks properly, by requiring packagers use the > --hard-dereference option in tar-1.19.90 when creating packages, That's especially nice because some people already have an older 'tar' installed. Only packagers would need the latest. > and (c) > we would *guarantee* that nobody would try to use WinZip to unpack the > archive, with its notorious "Smart [that is, extremely dumb] CR/LF > conversion" switch. Which is turned on, by default. I have my own winzip "war stories" like the one you posted on the users' list at 02:50Z, and I agree that deliberate incompatibility with winzip is a desirable feature. |
From: Earnie B. <ea...@us...> - 2008-04-22 12:07:58
|
Quoting Charles Wilson <cwi...@us...>: > > In this scenario, I'd definitely prefer lzma -- but I don't think that's > one of the file-type choices on SourceForge (except "Other Binary > Package" and "Other Source File") > We could ask they add it in a feature request. After all MinGW/MSYS is an "Operation System" choice. >> However, we have seen evidence on the MSYS list, where more than one >> user has broken his MSYS installation by using some other archiving >> tool, and so getting tools installed in a /usr hierarchy which becomes >> occluded by the MSYS loopback mount of /usr on /. (It was this which >> prompted my escalation of Earnie's original request to repackage the >> tarballs relative to /, rather than to /usr; that may have been >> something of an exercise in futility, if we do stipulate that only MSYS >> tar is supported for unpacking). > > Unless, as somebody suggested earlier -- and I mention above -- we > provide *mingw* command line tools specifically for unpacking these > archives. Those tools would not understand the msys mount system. > (Also, it might simplify the installer code if it didn't have to worry > about intercepting file names when unpacking). So, the repackaging form > /usr -> / *had* to be done. I'm just miffed at having to do it *again* > for naming/compression format reasons. If I'm going to do THAT, let's > at least keep it down to *one* more re-spin, not two. > Understandable. We might wish to take a look at http://sourceforge.net/projects/sfutils/ to see if there is anything there to help us with the FRS. Earnie |
From: Charles W. <cwi...@us...> - 2008-04-22 04:36:58
|
Greg Chicares wrote: > gnuwin32 gnutar has dependencies on two dlls that it provides: > > $cygcheck c:/Program\ Files/GnuWin32/bin/tar.exe |sed -e'/WINDOWS/d' > c:/Program Files/GnuWin32/bin/tar.exe > c:/Program Files/GnuWin32/bin\libintl-2.dll > c:/Program Files/GnuWin32/bin\libiconv-2.dll > > I wonder whether those dlls would conflict with other versions > that a user might have installed? I keep trying to get the > source in order to see whether it can be built without those > dependencies, but the sourceforge download site is unusually > unresponsive tonight. Yes, I knew the existing build relies on gettext and iconv. There's two ways around that: rebuild and link statically, using the gettext and libiconv mingwPORTs (my preference, so as to preserve non-ASCII filename support), or rebuild with --disable-nls. > The current installer seems to be NSIS, whose documentation > says it supports lzma: > http://nsis.sourceforge.net/Features > | three different integrated compression methods (ZLib, BZip2, LZMA) That's good to know. > That's especially nice because some people already have an > older 'tar' installed. Only packagers would need the latest. Yep -- and that is what would allow end users to use 7zip to unpack if they wanted to. > I have my own winzip "war stories" like the one you posted > on the users' list at 02:50Z, and I agree that deliberate > incompatibility with winzip is a desirable feature. <G> -- Chuck |
From: Earnie B. <ea...@us...> - 2008-04-22 11:43:04
|
Quoting Charles Wilson <cwi...@us...>: > > Yes, I knew the existing build relies on gettext and iconv. There's two > ways around that: rebuild and link statically, using the gettext and > libiconv mingwPORTs (my preference, so as to preserve non-ASCII filename > support), or rebuild with --disable-nls. > I have mixed feelings. I would like to advocate the shared libraries but I can certainly understand wanting static libraries since tar is perhaps used to extract those very libraries. For the mingw-tar binary package we perhaps should use zip format so that windows users unpack the bin directory containing the two dll and tar.exe? >> The current installer seems to be NSIS, whose documentation >> says it supports lzma: >> http://nsis.sourceforge.net/Features >> | three different integrated compression methods (ZLib, BZip2, LZMA) > > That's good to know. > Agreed but given that we are likely to redo the installer to be more Cygwin like it shouldn't matter which format we choose. Frankly, I don't particularly like the scripting syntaxes of the install builders I've used thus far; so, I support the move to setup.exe. >> That's especially nice because some people already have an >> older 'tar' installed. Only packagers would need the latest. > > Yep -- and that is what would allow end users to use 7zip to unpack if > they wanted to. > This is good. >> I have my own winzip "war stories" like the one you posted >> on the users' list at 02:50Z, and I agree that deliberate >> incompatibility with winzip is a desirable feature. > WinZip has never been a MinGW desirable feature and users are cautioned in our documentation. Earnie |
From: Charles W. <cwi...@us...> - 2008-04-22 05:24:58
|
Aaron W. LaFramboise wrote: > Charles Wilson wrote: >> gcc for both dwarf2 and sjlj. But if so, then this discussion should >> also include: >> >> foo-dw2 and foo-sjlj > > This is too much insanity. I've proposed here > <http://sourceforge.net/mailarchive/message.php?msg_name=47F6B2DE.5080709%40aaronwl.com> > only supporting Dwarf exceptions GCC4 and forward. I do not plan to > produce GCC4 binaries that support SJLJ exceptions unless someone > produces a compelling argument. Fine by me. So there's no need for any foo-<exceptionstyle> at all, going forward. That makes things simpler. -- Chuck |
From: Earnie B. <ea...@us...> - 2008-04-22 11:28:04
|
Quoting Charles Wilson <cwi...@us...>: > Aaron W. LaFramboise wrote: >> Charles Wilson wrote: >>> gcc for both dwarf2 and sjlj. But if so, then this discussion should >>> also include: >>> >>> foo-dw2 and foo-sjlj >> >> This is too much insanity. I've proposed here >> <http://sourceforge.net/mailarchive/message.php?msg_name=47F6B2DE.5080709%40aaronwl.com> >> only supporting Dwarf exceptions GCC4 and forward. I do not plan to >> produce GCC4 binaries that support SJLJ exceptions unless someone >> produces a compelling argument. > > Fine by me. So there's no need for any foo-<exceptionstyle> at all, > going forward. That makes things simpler. > I wouldn't go as far to say that. I would like to see -mingw32 and -mingw64 at some point. ;) As far as dw2 vs sjlj I think what Aaron proposes is fine. Earnie |
From: Gianluca S. <gi...@gm...> - 2008-04-22 09:27:25
|
On Tue, Apr 22, 2008 at 12:37 AM, Earnie Boyd <ea...@us...> wrote: > > 4) able to query the SF page for availability of updated packages > > > > How do you propose to do that? For instance, parsing: http://sourceforge.net/export/rss2_projfiles.php?group_id=2435 could be an approach. Otherwise, we can run a daily cron job to prepare the required metadata to be consumed the installer/updater. |
From: Earnie B. <ea...@us...> - 2008-04-22 11:24:56
|
Quoting Gianluca Sforna <gi...@gm...>: > On Tue, Apr 22, 2008 at 12:37 AM, Earnie Boyd > <ea...@us...> wrote: >> > 4) able to query the SF page for availability of updated packages >> > >> >> How do you propose to do that? > > For instance, parsing: > > http://sourceforge.net/export/rss2_projfiles.php?group_id=2435 > > could be an approach. > > Otherwise, we can run a daily cron job to prepare the required > metadata to be consumed the installer/updater. > If I had assurance that the file tags would change maybe. Perhaps a simple call to a RSS reader with the above URL would suffice. Earnie |
From: Charles W. <cwi...@us...> - 2008-04-23 14:25:42
|
Earnie Boyd wrote: > I would like the > <package>.setup to contain an email address for sending parse errors to. Couldn't this mapping between packages and email addy for the last-known-uploader for that package be maintained in a private database, rather than a public file? Better yet, isn't the sf account of the person who set the File Type for a given uploaded file -- or who added to a release a specific file (such as <pkg>.hint) already recorded in some sf database? Let's not make it TOO easy for the harvesters... -- Chuck |
From: Earnie B. <ea...@us...> - 2008-04-23 21:11:49
|
Quoting Charles Wilson <cwi...@us...>: > Earnie Boyd wrote: >> I would like the >> <package>.setup to contain an email address for sending parse errors to. > > Couldn't this mapping between packages and email addy for the > last-known-uploader for that package be maintained in a private > database, rather than a public file? Better yet, isn't the sf account of > the person who set the File Type for a given uploaded file -- or who > added to a release a specific file (such as <pkg>.hint) already recorded > in some sf database? > Does it matter? The SF user is harvestable already. :) Ok, rather than email address the SF user id, in the file. I don't think I can get it from any SF db. > Let's not make it TOO easy for the harvesters... > A spammer can use id @ sf dot net and send you email; all it needs to do is read the list of SF support requests. Earnie |
From: Keith M. <kei...@us...> - 2008-04-23 23:28:53
Attachments:
pkginfo.l
|
On Tuesday 22 April 2008 02:06, Charles Wilson wrote: >> ... Suppose we >> view the package naming convention in terms of the schema:-- >> >> <archive-name> ::= <pkg-id>["-"<subsystem-id>]"-"<type-id> >> <pkg-id> ::= <pkg-name>"-"<version>["-"<build-id>] >> <subsystem-id> ::= <subsystem-name>["-"<version>]["-"<build-id>] >> <type-id> ::= <component-id>"."<format-type>["."<compression-type>] >> <version> ::= <major>["."<minor>["."<patchlevel>]] >> <build-id> ::= <datestamp>["-"<serial-number>] | <serial-number> >> <component-id> ::= <component-class>["-"<version>] >> <component-class> ::= "bin" | "dev" | "dll" | "src" | "mingwPORT" >> <format-type> ::= "tar" | "exe" | "zip" >> <compression-type> ::= "gz" | "bz2" | ... >> >> Now, for example, you have >> `guile-1.8.4-MSYS-1.0.11-1-dll17.tar.gz', which in terms of the >> schema, gives us:-- >> >> Package Name: guile >> Package Version: 1.8.4 (major = 1; minor = 8; >> patchlevel = 4) >> Package Build: unspecified >> >> Subsystem Name: MSYS >> Subsystem Version: 1.0.11 (major = 1; minor = 0; >> patchlevel = 11) >> Subsystem Build: 1 (datestamp unspecified; >> serial no = 1) >> >> Component Class: dll >> Component Version: 17 (assuming implicit separator => >> dll-17) >> >> Archive Format: tar >> Compression Type: gz >> >> Aside from the issue of the omitted separator in `dll-17', which >> we've noted before, and have yet to agree formally on its >> advisability, > > I drop any objections to the '-' between ComponentClass and > ComponentVersion. Ok, for reasons which I'll clarify below, I'd suggest that we adopt the `<component-id> ::= <component-class>["-"<component-version>]' form. > The only problem I have with the specified schema > is that I *think* it is not possible for a non-human to parse it > unambiguously if there are missing fields. I had my doubts too, so I created the attached rudimentary analyser; (disclaimer: I am no lex expert; I'm sure this could be improved). It attempts to implement the above schema, albeit hardly robustly, and with a few caveats and loopholes. Note, in particular: 1) It *does* require the form <component-id> ::= <component-name>["-"<component-version>] 2) It would accept your originally proposed alternative form <component-id> ::= <component-name>[<component-version>] but with this form, it would be unable to segregate the two elements, simply collapsing to <component-id> ::= <component-name-and-version> encoded as a single field; hence my proposal to adopt (1). 3) It accepts, but in its present form, does not enforce <version> ::= <major>["."<minor>["."<patchlevel>]] nor does it decompose <version> into its constituent elements; it requires only that <major> comprises exclusively decimal digits, and that each of <minor> and <patchlevel> *begin* with a decimal digit; (this allows a version such as man's 1.6e, for the release I am preparing at present); subject to these constraints, it extracts <version> in its entirety, as a single entity. 4) It does *not* rigorously implement either <build-id> ::= <datestamp>["-"<serial-number>] | <serial-number> or <build-id> ::= <datestamp>"-"<serial-number> | <serial-number> Rather, it implements <build-id> ::= <serial-number>{"-"<serial-number>} (i.e. an arbitrarily repeating sequence of <serial-numbers>); it *does* require that the first character of each <serial-number> be a decimal digit, and the first could just as well represent a datestamp, in the form `20080423', so it is at best a loose fit for the intended rule. 5) It does *not* correctly implement <subsystem-id> ::= <subsystem-name>["-"<version>]["-"<build-id>] instead implementing it as <subsystem-id> ::= <subsystem-name>["-"<version>["-"<build-id>]] which implies that a <build-id> cannot follow the <subsystem-name>, *unless* the subsystem is versioned; that may be ok for MSYS, but if we adopt Earnie's suggestion of ultimately identifying mingw32 and mingw64 subsystems, (he suggested it first, but I have also been thinking that it may be advisable), do we really want to version these? I think not. > The individualized pieces specified in the version|subsys key are > unambiguously parseable, with the following change: > > <build-id> ::= <datestamp>"-"<serial-number> | <serial-number> > > That is, if you have <datestamp>, you *must* have <serial-number>. > That way, taking either the version half of the version|subsys key, > or the subsys half, if there are four '-' separated fields, then #3 > is <datestamp> and #4 is <serial-number>. If there are only three > fields, then #3 is <serial-number>. This may be the ideal scenario; as I've written my analyser, it lacks the constraints necessary to parse it thus; see (4) and (5) above. Here are some examples of this analyser in action: $ make LEX=flex pkginfo flex -t pkginfo.l > pkginfo.c cc -c -o pkginfo.o pkginfo.c cc pkginfo.o -o pkginfo rm pkginfo.c pkginfo.o first, the `guile' example, from above: $ ./pkginfo guile-1.8.4-MSYS-1.0.11-1-dll17.tar.gz Package Name: guile Package Version: 1.8.4 Package Build: <unspecified> Subsystem Name: MSYS Subsystem Version: 1.0.11 Subsystem Build: 1 Component Type: dll17 Component Version: <unspecified> Archive Format: tar Compression Type gz but, adding a hyphen in the <component-id>: $ ./pkginfo guile-1.8.4-MSYS-1.0.11-1-dll-17.tar.gz Package Name: guile Package Version: 1.8.4 Package Build: <unspecified> Subsystem Name: MSYS Subsystem Version: 1.0.11 Subsystem Build: 1 Component Type: dll Component Version: 17 Archive Format: tar Compression Type gz a current MinGW package, with <component-id> added: $ ./pkginfo binutils-2.18.50-20080109-2-bin.tar.gz Package Name: binutils Package Version: 2.18.50 Package Build: 20080109-2 Subsystem Name: <unspecified> Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz but see how it breaks, if <component-id> is omitted: $ ./pkginfo binutils-2.18.50-20080109-2.tar.gz Package Name: binutils Package Version: 2.18.50 Package Build: 20080109-2.tar.gz? Subsystem Name: <unspecified> Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: <unspecified> Component Version: <unspecified> Archive Format: <unspecified> Compression Type <unspecified> we may add a <subsystem-id> *after* the package <build-id>: $ ./pkginfo binutils-2.18.50-20080109-2-mingw32-bin.tar.gz Package Name: binutils Package Version: 2.18.50 Package Build: 20080109-2 Subsystem Name: mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz but, without versioning `mingw32', it is less happy to be placed before the <build-id>: $ ./pkginfo binutils-2.18.50-mingw32-20080109-2-bin.tar.gz Package Name: binutils Package Version: 2.18.50 Package Build: <unspecified> Subsystem Name: mingw32 Subsystem Version: 20080109 Subsystem Build: 2 Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz and finally, Aaron's latest gcc alpha release needs a `-bin', to pacify this analyser; thus: $ ./pkginfo gcc-4.3.0-mingw-alpha-20080403.tar.gz Package Name: gcc Package Version: 4.3.0 Package Build: <unspecified> Subsystem Name: mingw Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: alpha Component Version: 20080403 Archive Format: tar Compression Type gz really wants to become: $ ./pkginfo gcc-4.3.0-mingw32-alpha-20080403-bin.tar.gz Package Name: gcc Package Version: 4.3.0 Package Build: <unspecified> Subsystem Name: mingw32-alpha Subsystem Version: 20080403 Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz if Aaron is happy with `20080403' being interpreted as <version> for the `mingw32-alpha' subsystem, and not <build-id> for his package, (and do note explicitly `mingw32', and not just `mingw'; this is a binary for mingw32, but it is not for mingw64). If Aaron isn't happy with this interpretation, then perhaps it should rather be: $ ./pkginfo gcc-4.3.0-20080403-mingw32-alpha-bin.tar.gz Package Name: gcc Package Version: 4.3.0 Package Build: 20080403 Subsystem Name: mingw32-alpha Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz or better still: $ ./pkginfo gcc-4.3.0-20080403-1-mingw32-alpha-bin.tar.gz Package Name: gcc Package Version: 4.3.0 Package Build: 20080403-1 Subsystem Name: mingw32-alpha Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz > I don't know if that is important. It may be, if you want automated > package/dependency management. However, we are not required to infer > this information from the package names. You could instead have your > package manager use ancillary files ... True. The wx toy I've created uses an informal XML schema, (informal because the DTD lives exclusively in my head, and I can modify it on a whim), and parses that using wx's standard XML classes, (which use expat, I believe), so I don't *need* to derive this info from the package names; however, I do still believe that a consistent standard package naming convention, which is congruent with such an XML schema, is desireable... > (like cygwin's setup.exe's setup.hint/setup.ini, ...and IMO, the same argument holds, if we choose to adopt this. Regards, Keith. |
From: Aaron W. L. <aar...@aa...> - 2008-05-03 22:28:19
|
Keith, see below. Keith Marshall wrote: > * pkginfo.l > * > * A simple lexical analyser for decomposing package archive names into their > * constituent components. It implements the schema:-- Thanks for writing this thing; this is exactly what we needed to clarify the new proposed system. I propose that we make this lexer the official reference on MinGW packaging, if we finalize this new system. I have three issues though. 1) It doesn't handle the situation where the archiver is also the compression method. This is needed for ZIP, 7-Zip, the tgz shorthand, and similar. ./pkginfo gcc-2.7.2-bin.zip Package Name: gcc Package Version: 2.7.2 Package Build: <unspecified> Subsystem Name: bin.zip? Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: <unspecified> Component Version: <unspecified> Archive Format: <unspecified> Compression Type <unspecified> 2) What is the 'component version' field for? Maybe I missed this in the discussion. 3) There doesn't seem to be a way to indicate the status of a package in the filename using alphabetical characters, such as 'beta' or 'experimental.' I'd like to be able to do something like the following. ./pkginfo gcc-2.7.2-experimental-mingw32-bin.tar.gz Package Name: gcc Package Version: 2.7.2 Package Build: <unspecified> Subsystem Name: experimental-mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz But I would prefer that 'experimental' not be part of the subsystem name, as the release status of this package really has nothing to do with the target system. |
From: Keith M. <kei...@us...> - 2008-05-04 00:08:43
|
On Saturday 03 May 2008 23:27, Aaron W. LaFramboise wrote: > I have three issues though. > > 1) It doesn't handle the situation where the archiver is also the > compression method. This is needed for ZIP, 7-Zip, the tgz > shorthand, and similar. A bug. The schema says the final `compression-type' element is to be optional, but the implementation doesn't allow it to be. I'll follow up on it tomorrow. > 2) What is the 'component version' field for? Maybe I missed this in > the discussion. Primarily to accommodate DLL versioning, per Chuck's recommendation, while conforming to my preference for dll-1 rather than dll1, say. > 3) There doesn't seem to be a way to indicate the status of a package > in the filename using alphabetical characters, such as 'beta' or > 'experimental.' I'd like to be able to do something like the > following. The current lexer implementation isn't quite as strict about the format of the package version number, as the schema would suggest; only the major part is actually constrained to comprise only digits, and the number of subfields isn't restricted to three, so rather than > ./pkginfo gcc-2.7.2-experimental-mingw32-bin.tar.gz you could have $ ./pkginfo gcc-2.7.2.experimental-mingw32-bin.tar.gz Package Name: gcc Package Version: 2.7.2.experimental Package Build: <unspecified> Subsystem Name: mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type gz Perhaps not ideal, but it does fit with... > But I would prefer that 'experimental' not be part of the subsystem > name, as the release status of this package really has nothing to do > with the target system. Alternatively, you could perhaps just consider including it as a suffix to the system type; `mingw32-experimental' seems somehow more logical than `experimental-mingw32', (and is consistent with the `mingw-beta' I used for the first `man' package). Of course, the lexer could be augmented to recognise additional cases, but I prefer to avoid adding too many variations; that kind of defeats the objective of standardisation. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-05-04 12:36:11
|
On Sunday 04 May 2008 01:08, Keith Marshall wrote: > > 1) It doesn't handle the situation where the archiver is also the > > compression method. This is needed for ZIP, 7-Zip, the tgz > > shorthand, and similar. > > A bug. The schema says the final `compression-type' element is to be > optional, but the implementation doesn't allow it to be. I'll follow > up on it tomorrow. I believe this fixes it:-- Index: pkginfo.l =================================================================== RCS file: /home/keith/cvsroot/mingw/pkginfo/pkginfo.l,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 pkginfo.l --- pkginfo.l 4 May 2008 12:13:09 -0000 1.1.1.1 +++ pkginfo.l 4 May 2008 12:24:28 -0000 @@ -109,7 +109,7 @@ return mark += yyleng; } -<TRANS>[^-0-9.][^-.]+(-[0-9][^-.]*){0,1}\.[^-.]+\.[^-.]+\? { +<TRANS>[^-0-9.][^-.]+(-[0-9][^-.]*){0,1}(\.[^-.]+){1,2}\? { /* * Transitional case rule... * Identify a following terminal <type-id> sequence; set up $ ./pkginfo gcc-2.7.2-bin.zip Package Name: gcc Package Version: 2.7.2 Package Build: <unspecified> Subsystem Name: <unspecified> Subsystem Version: <unspecified> Subsystem Build: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: zip Compression Type <unspecified> Regards, Keith. |
From: Aaron W. L. <aar...@aa...> - 2008-05-04 06:57:06
|
Keith Marshall wrote: >> 2) What is the 'component version' field for? Maybe I missed this in >> the discussion. > > Primarily to accommodate DLL versioning, per Chuck's recommendation, > while conforming to my preference for dll-1 rather than dll1, say. So this is intended to indicate an API or interface version? That is, "dll" packages with the same component version but different package versions still should be ABI-compatible? > Alternatively, you could perhaps just consider including it as a suffix > to the system type; `mingw32-experimental' seems somehow more logical > than `experimental-mingw32', (and is consistent with the `mingw-beta' I > used for the first `man' package). OK; so just to restate this, the standard here is that these additional 'development phase' modifiers should be suffixes to the subsystem. |
From: Keith M. <kei...@us...> - 2008-05-04 09:57:08
|
On Sunday 04 May 2008 07:56, Aaron W. LaFramboise wrote: > >> 2) What is the 'component version' field for? Maybe I missed this > >> in the discussion. > > > > Primarily to accommodate DLL versioning, per Chuck's > > recommendation, while conforming to my preference for dll-1 rather > > than dll1, say. > > So this is intended to indicate an API or interface version? That > is, "dll" packages with the same component version but different > package versions still should be ABI-compatible? Yes. > > Alternatively, you could perhaps just consider including it as a > > suffix to the system type; `mingw32-experimental' seems somehow > > more logical than `experimental-mingw32', (and is consistent with > > the `mingw-beta' I used for the first `man' package). > > OK; so just to restate this, the standard here is that these > additional 'development phase' modifiers should be suffixes to the > subsystem. That's what I propose, yes, but I'm open to alternative suggestions. The important thing is to adopt a consistent standard, which can be readily expressed as a `grammar' for analysis by the computer, to facilitate possible eventual use by package management software. BTW, I like the terminology `development phase modifier'; thanks for suggesting it. Conceptually, it's something which I too have thought could be usefully added to the schema for a package naming convention. Perhaps, to facilitate identification, we could define a small set of predetermined keywords, which the lexer could look for, say as a suffix to the subsystem name. Any alternative ideas? Anybody? Regards, Keith. |