Menu
▾
▴
mingw-dvlpr
|
From: Earnie B. <ea...@us...> - 2013-02-25 14:53:29
|
I'm nearing being ready to give a release candidate for 4.0. I've completed the release notes[1] which I would like a review. How should we go about doing this release candidate? We don't want mingw-get installing this by default; there is an ABI change that will cause a need to rebuild any libraries using opendir and friends. The release candidate has two purposes, first is the typical testing of a package and secondly is a preparation of packages for the up-and-coming official release. [1] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/b3dee57ccbf6f9c4d54e59c122eab562d1582706/tree/NEWS -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-02-26 15:35:20
|
On Mon, Feb 25, 2013 at 9:53 AM, Earnie Boyd wrote: > I'm nearing being ready to give a release candidate for 4.0. I've > completed the release notes[1] which I would like a review. > > How should we go about doing this release candidate? We don't want > mingw-get installing this by default; there is an ABI change that will > cause a need to rebuild any libraries using opendir and friends. The > release candidate has two purposes, first is the typical testing of a > package and secondly is a preparation of packages for the > up-and-coming official release. > > [1] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/b3dee57ccbf6f9c4d54e59c122eab562d1582706/tree/NEWS Also are these package names good for a release candidate? mingwrt-4.0-rc1-1-mingw32-dev.tar.lzma mingwrt-4.0-rc1-1-mingw32-dll.tar.lzma mingwrt-4.0-rc1-1-mingw32-doc.tar.lzma mingwrt-4.0-rc1-1-mingw32-lic.tar.lzma mingwrt-4.0-rc1-1-mingw32-src.tar.lzma w32api-4.0-rc1-1-mingw32-dev.tar.lzma w32api-4.0-rc1-1-mingw32-doc.tar.lzma w32api-4.0-rc1-1-mingw32-lic.tar.lzma w32api-4.0-rc1-1-mingw32-src.tar.lzma -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-02-26 18:47:45
|
On Tue, Feb 26, 2013 at 10:34 AM, Earnie Boyd wrote: > On Mon, Feb 25, 2013 at 9:53 AM, Earnie Boyd wrote: >> I'm nearing being ready to give a release candidate for 4.0. I've >> completed the release notes[1] which I would like a review. >> >> How should we go about doing this release candidate? We don't want >> mingw-get installing this by default; there is an ABI change that will >> cause a need to rebuild any libraries using opendir and friends. The >> release candidate has two purposes, first is the typical testing of a >> package and secondly is a preparation of packages for the >> up-and-coming official release. >> >> [1] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/b3dee57ccbf6f9c4d54e59c122eab562d1582706/tree/NEWS > > Also are these package names good for a release candidate? > > mingwrt-4.0-rc1-1-mingw32-dev.tar.lzma > mingwrt-4.0-rc1-1-mingw32-dll.tar.lzma > mingwrt-4.0-rc1-1-mingw32-doc.tar.lzma > mingwrt-4.0-rc1-1-mingw32-lic.tar.lzma > mingwrt-4.0-rc1-1-mingw32-src.tar.lzma > w32api-4.0-rc1-1-mingw32-dev.tar.lzma > w32api-4.0-rc1-1-mingw32-doc.tar.lzma > w32api-4.0-rc1-1-mingw32-lic.tar.lzma > w32api-4.0-rc1-1-mingw32-src.tar.lzma Does this diff to mingw32-runtime.xml look feasible for the release candidate? We could remove it later and move the release to the previous package releases. diff --git a/mingw32/mingw32-runtime.xml b/mingw32/mingw32-runtime.xml index 59a92d3..379f5ae 100644 --- a/mingw32/mingw32-runtime.xml +++ b/mingw32/mingw32-runtime.xml @@ -72,6 +72,63 @@ </component> </package> + <package name="mingw32-mingwrt-4-0-rc1" alias="mingwrt-4-0-rc1"> + <affiliate group="MinGW Compiler Suite" /> + <affiliate group="MinGW Standard Libraries" /> + <description lang="en" title="The MinGW Runtime Library API"> + <paragraph> + This package provides the header files, system object modules, + dynamic link libraries, import libraries and static libraries + which constitute the standard MinGW Runtime API. + </paragraph> + <paragraph> + This is a required component of the MinGW Compiler Suite. + </paragraph> + </description> + + <source tarname="mingwrt-4.0-rc1-1-mingw32-src.tar.lzma" /> + <license tarname="mingwrt-4.0-rc1-1-mingw32-lic.tar.lzma" /> + + <component class="dev"> + <release tarname="mingwrt-4.0-rc1-1-mingw32-dev.tar.lzma" /> + </component> + + <component class="dll"> + <release tarname="mingwrt-4.0-rc1-1-mingw32-dll.tar.lzma" /> + </component> + + <component class="doc"> + <release tarname="mingwrt-4.0-rc1-1-mingw32-doc.tar.lzma" /> + </component> + </package> + + <package name="mingw32-w32api-4-0-rc1" alias="w32api-4-0-rc1"> + <affiliate group="MinGW Compiler Suite" /> + <affiliate group="MinGW Standard Libraries" /> + <description lang="en" title="The MinGW API for 32-Bit MS-Windows"> + <paragraph> + This package provides the header files, and import libraries + constituting a standard API for the development of applications + which utilise the capabilities of the 32-bit MS-Windows system + dynamic link libraries. + </paragraph> + <paragraph> + This is a required component of the MinGW Compiler Suite. + </paragraph> + </description> + + <source tarname="w32api-4.0-rc1-mingw32-src.tar.lzma" /> + <licence tarname="w32api-4.0-rc1-mingw32-lic.tar.lzma" /> + + <component class="dev"> + <release tarname="w32api-4.0-rc1-1-mingw32-dev.tar.lzma" /> + </component> + + <component class="doc"> + <release tarname="w32api-4.0-rc1-1-mingw32-doc.tar.lzma" /> + </component> + </package> + </package-collection> </software-distribution> <!-- vim: set nocompatible expandtab fileformat=unix textwidth=80 tabstop=2 shiftwidth=2: --> -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Keith M. <kei...@us...> - 2013-02-26 20:46:29
|
I still need to give some thought to your earlier post; however, in respect of: On 26/02/13 15:34, Earnie Boyd wrote: > Also are these package names good for a release candidate? > > mingwrt-4.0-rc1-1-mingw32-dev.tar.lzma > ... mingw-get says "no". You should use its pkginfo tool to evaluate proposed package names, within the context in which mingw-get will interpret them: $ pkginfo mingwrt-4.0-rc1-1-mingw32-dev.tar.lzma Package Name: mingwrt Package Version: 4.0 Package Build: <unspecified> Subsystem Name: rc1 Subsystem Version: 1 Subsystem Build: <unspecified> Release Status: mingw32 Release Reference: <unspecified> Component Type: dev Component Version: <unspecified> Archive Format: tar Compression Type lzma I really don't think you intended to specify subsystem rc1 version 1; neither do I think that you want: $ pkginfo mingwrt-4.0-mingw32-rc1-1-dev.tar.lzma Package Name: mingwrt Package Version: 4.0 Package Build: <unspecified> Subsystem Name: mingw32-rc1 Subsystem Version: 1 Subsystem Build: <unspecified> Release Status: <unspecified> Release Reference: <unspecified> Component Type: dev Component Version: <unspecified> Archive Format: tar Compression Type lzma Formally acceptable, and more realistic perhaps: $ pkginfo mingwrt-4.0-mingw32-rc-1-dev.tar.lzma Package Name: mingwrt Package Version: 4.0 Package Build: <unspecified> Subsystem Name: mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Release Status: rc Release Reference: 1 Component Type: dev Component Version: <unspecified> Archive Format: tar Compression Type lzma Valid variations you may wish to consider; (I leave it as an exercise for yourself, to determine the pkginfo interpretation): mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma mingwrt-4.0-1-mingw32-rc-1-20130226-dev.tar.lzma mingwrt-4.0-1-20130226-mingw32-rc-1-dev.tar.lzma -- Regards, Keith. |
|
From: Earnie B. <ea...@us...> - 2013-02-27 13:33:31
|
On Tue, Feb 26, 2013 at 3:45 PM, Keith Marshall wrote: Thanks for the information Keith. > Valid variations you may wish to consider; (I leave it as an exercise > for yourself, to determine the pkginfo interpretation): > > mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma I chose this one since I'm doing this in Makefile.in. I now set RELEASE_STATUS and RELEASE_REFERENCE variables. If RELEASE_STATUS = prod then it isn't used in the creation of the file for the dist-mingwrt and the like targets. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-02-27 22:23:37
|
On Wed, Feb 27, 2013 at 8:33 AM, Earnie Boyd wrote:
> On Tue, Feb 26, 2013 at 3:45 PM, Keith Marshall wrote:
>
> Thanks for the information Keith.
>
>> Valid variations you may wish to consider; (I leave it as an exercise
>> for yourself, to determine the pkginfo interpretation):
>>
>> mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma
>
> I chose this one since I'm doing this in Makefile.in. I now set
> RELEASE_STATUS and RELEASE_REFERENCE variables. If RELEASE_STATUS =
> prod then it isn't used in the creation of the file for the
> dist-mingwrt and the like targets.
So we now have:
diff --git a/mingw32/mingw32-runtime.xml b/mingw32/mingw32-runtime.xml
index 59a92d3..cfb2b11 100644
--- a/mingw32/mingw32-runtime.xml
+++ b/mingw32/mingw32-runtime.xml
@@ -72,6 +72,63 @@
</component>
</package>
+ <package name="mingw32-mingwrt-4-0-rc1" alias="mingwrt-4-0-rc1">
+ <affiliate group="MinGW Compiler Suite" />
+ <affiliate group="MinGW Standard Libraries" />
+ <description lang="en" title="The MinGW Runtime Library API">
+ <paragraph>
+ This package provides the header files, system object modules,
+ dynamic link libraries, import libraries and static libraries
+ which constitute the standard MinGW Runtime API.
+ </paragraph>
+ <paragraph>
+ This is a required component of the MinGW Compiler Suite.
+ </paragraph>
+ </description>
+
+ <source tarname="mingwrt-4.0-1-mingw32-rc-1-src.tar.lzma" />
+ <license tarname="mingwrt-4.0-1-mingw32-rc-1-lic.tar.lzma" />
+
+ <component class="dev">
+ <release tarname="mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma" />
+ </component>
+
+ <component class="dll">
+ <release tarname="mingwrt-4.0-1-mingw32-rc-1-dll.tar.lzma" />
+ </component>
+
+ <component class="doc">
+ <release tarname="mingwrt-4.0-1-mingw32-rc-1-doc.tar.lzma" />
+ </component>
+ </package>
+
+ <package name="mingw32-w32api-4-0-rc1" alias="w32api-4-0-rc1">
+ <affiliate group="MinGW Compiler Suite" />
+ <affiliate group="MinGW Standard Libraries" />
+ <description lang="en" title="The MinGW API for 32-Bit MS-Windows">
+ <paragraph>
+ This package provides the header files, and import libraries
+ constituting a standard API for the development of applications
+ which utilise the capabilities of the 32-bit MS-Windows system
+ dynamic link libraries.
+ </paragraph>
+ <paragraph>
+ This is a required component of the MinGW Compiler Suite.
+ </paragraph>
+ </description>
+
+ <source tarname="w32api-4.0-1-mingw32-rc-1-src.tar.lzma" />
+ <licence tarname="w32api-4.0-1-mingw32-rc-1-lic.tar.lzma" />
+
+ <component class="dev">
+ <release tarname="w32api-4.0-1-mingw32-rc-1-dev.tar.lzma" />
+ </component>
+
+ <component class="doc">
+ <release tarname="w32api-4.0-1-mingw32-rc-1-doc.tar.lzma" />
+ </component>
+ </package>
+
</package-collection>
</software-distribution>
<!-- vim: set nocompatible expandtab fileformat=unix textwidth=80
tabstop=2 shiftwidth=2: -->
Is this acceptable?
--
Earnie
-- https://sites.google.com/site/earnieboyd
|
|
From: Earnie B. <ea...@us...> - 2013-02-27 21:31:29
|
On Wed, Feb 27, 2013 at 2:42 PM, Earnie Boyd wrote: > On Wed, Feb 27, 2013 at 8:33 AM, Earnie Boyd wrote: >> On Tue, Feb 26, 2013 at 3:45 PM, Keith Marshall wrote: >> >> Thanks for the information Keith. >> >>> Valid variations you may wish to consider; (I leave it as an exercise >>> for yourself, to determine the pkginfo interpretation): >>> >>> mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma >> >> I chose this one since I'm doing this in Makefile.in. I now set >> RELEASE_STATUS and RELEASE_REFERENCE variables. If RELEASE_STATUS = >> prod then it isn't used in the creation of the file for the >> dist-mingwrt and the like targets. > > So we now have: > > diff --git a/mingw32/mingw32-runtime.xml b/mingw32/mingw32-runtime.xml > index 59a92d3..cfb2b11 100644 > --- a/mingw32/mingw32-runtime.xml > +++ b/mingw32/mingw32-runtime.xml > @@ -72,6 +72,63 @@ > </component> > </package> > > + <package name="mingw32-mingwrt-4-0-rc1" alias="mingwrt-4-0-rc1"> > + <affiliate group="MinGW Compiler Suite" /> > + <affiliate group="MinGW Standard Libraries" /> > + <description lang="en" title="The MinGW Runtime Library API"> > + <paragraph> > + This package provides the header files, system object modules, > + dynamic link libraries, import libraries and static libraries > + which constitute the standard MinGW Runtime API. > + </paragraph> > + <paragraph> > + This is a required component of the MinGW Compiler Suite. > + </paragraph> > + </description> > + > + <source tarname="mingwrt-4.0-1-mingw32-rc-1-src.tar.lzma" /> > + <license tarname="mingwrt-4.0-1-mingw32-rc-1-lic.tar.lzma" /> > + > + <component class="dev"> > + <release tarname="mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma" /> > + </component> > + > + <component class="dll"> > + <release tarname="mingwrt-4.0-1-mingw32-rc-1-dll.tar.lzma" /> > + </component> > + > + <component class="doc"> > + <release tarname="mingwrt-4.0-1-mingw32-rc-1-doc.tar.lzma" /> > + </component> > + </package> > + > + <package name="mingw32-w32api-4-0-rc1" alias="w32api-4-0-rc1"> > + <affiliate group="MinGW Compiler Suite" /> > + <affiliate group="MinGW Standard Libraries" /> > + <description lang="en" title="The MinGW API for 32-Bit MS-Windows"> > + <paragraph> > + This package provides the header files, and import libraries > + constituting a standard API for the development of applications > + which utilise the capabilities of the 32-bit MS-Windows system > + dynamic link libraries. > + </paragraph> > + <paragraph> > + This is a required component of the MinGW Compiler Suite. > + </paragraph> > + </description> > + > + <source tarname="w32api-4.0-1-mingw32-rc-1-src.tar.lzma" /> > + <licence tarname="w32api-4.0-1-mingw32-rc-1-lic.tar.lzma" /> > + > + <component class="dev"> > + <release tarname="w32api-4.0-1-mingw32-rc-1-dev.tar.lzma" /> > + </component> > + > + <component class="doc"> > + <release tarname="w32api-4.0-1-mingw32-rc-1-doc.tar.lzma" /> > + </component> > + </package> > + > </package-collection> > </software-distribution> > <!-- vim: set nocompatible expandtab fileformat=unix textwidth=80 > tabstop=2 shiftwidth=2: --> > > Is this acceptable? I gave this a test on my local system but I had to do both an upgrade and an install because of the new component classes. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Keith M. <kei...@us...> - 2013-03-01 21:55:05
|
On 27/02/13 21:29, Earnie Boyd wrote: > On Wed, Feb 27, 2013 at 2:42 PM, Earnie Boyd wrote: >> On Wed, Feb 27, 2013 at 8:33 AM, Earnie Boyd wrote: >> [...] >> So we now have: >> >> diff --git a/mingw32/mingw32-runtime.xml b/mingw32/mingw32-runtime.xml >> index 59a92d3..cfb2b11 100644 >> --- a/mingw32/mingw32-runtime.xml >> +++ b/mingw32/mingw32-runtime.xml >> @@ -72,6 +72,63 @@ >> </component> >> </package> >> >> + <package name="mingw32-mingwrt-4-0-rc1" alias="mingwrt-4-0-rc1"> Aside from this introducing the impression of mingw32 as default host, there may be package naming issues here; see below. >> + [...] >> + >> + <source tarname="mingwrt-4.0-1-mingw32-rc-1-src.tar.lzma" /> >> + <license tarname="mingwrt-4.0-1-mingw32-rc-1-lic.tar.lzma" /> >> + >> + <component class="dev"> >> + <release tarname="mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma" /> >> + </component> >> + >> + [...] >> + </package> >> + >> + <package name="mingw32-w32api-4-0-rc1" alias="w32api-4-0-rc1"> >> + [...] >> + >> + <source tarname="w32api-4.0-1-mingw32-rc-1-src.tar.lzma" /> >> + <licence tarname="w32api-4.0-1-mingw32-rc-1-lic.tar.lzma" /> >> + >> + <component class="dev"> >> + <release tarname="w32api-4.0-1-mingw32-rc-1-dev.tar.lzma" /> >> + </component> >> + >> + [...] >> + </package> >> + >> </package-collection> >> [...] >> >> Is this acceptable? > > I gave this a test on my local system but I had to do both an upgrade > and an install because of the new component classes. I'm surprised it worked at all; "mingw32-mingwrt-4-0-rc1" isn't a valid package name. If you substitute it into the logical representation of its associated tarname, as agreed in previous discussion, (in which the main participants were Chuck and myself, but to which you were also an invited party), you get mingwrt-4-0-rc1-4.0-mingw32-rc-1-dev.tar.lzma Run that through pkginfo, and you'll see the problem. Ditto, in the case of mingw32-w32api-4-0-rc1. I understand what you are trying to do, but in addition to this package naming anomaly, there is a more serious problem: you are breaking the rule of package orthogonality; (no individual file should be delivered by more than one package). In introducing this pair of packages, you are creating conflicts with the existing mingwrt and w32api packages; I'm afraid that current mingw-get just isn't equipped to handle any such scenario. -- Regards, Keith. |
|
From: Earnie B. <ea...@us...> - 2013-03-01 22:14:36
|
On Thu, Feb 28, 2013 at 8:40 AM, Keith Marshall wrote: > > I understand what you are trying to do, but in addition to this package Which is to have a RC package that isn't delivered as the most current by default. > naming anomaly, there is a more serious problem: you are breaking the > rule of package orthogonality; (no individual file should be delivered > by more than one package). In introducing this pair of packages, you > are creating conflicts with the existing mingwrt and w32api packages; > I'm afraid that current mingw-get just isn't equipped to handle any such > scenario. Suggestions? -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Keith M. <kei...@us...> - 2013-03-01 22:45:39
|
On 01/03/13 22:14, Earnie Boyd wrote: > On Thu, Feb 28, 2013 at 8:40 AM, Keith Marshall wrote: >> I understand what you are trying to do, but in addition to this package > > Which is to have a RC package that isn't delivered as the most current > by default. Yes, I got that. >> naming anomaly, there is a more serious problem: you are breaking the >> rule of package orthogonality; (no individual file should be delivered >> by more than one package). In introducing this pair of packages, you >> are creating conflicts with the existing mingwrt and w32api packages; >> I'm afraid that current mingw-get just isn't equipped to handle any such >> scenario. > > Suggestions? The technique I've used for mingw-get-gui is an option, (overriding the single catalogue file, for those who opt in). Another would be to offer a complete modified catalogue set, from a distinctly different host URL, with opt in by adjustment of the repository configuration in profile.xml Other than these, I don't think there's any alternative, without significant further development of mingw-get; (I eventually plan to add a policy configuration option, which would allow users to opt in or out of upgrades to non-stable classified releases, but that's still a long way off). -- Regards, Keith. |
|
From: Earnie B. <ea...@us...> - 2013-03-02 16:41:31
|
On Fri, Mar 1, 2013 at 5:45 PM, Keith Marshall wrote: > On 01/03/13 22:14, Earnie Boyd wrote: >> On Thu, Feb 28, 2013 at 8:40 AM, Keith Marshall wrote: >>> I understand what you are trying to do, but in addition to this package >> >> Which is to have a RC package that isn't delivered as the most current >> by default. > > Yes, I got that. > >>> naming anomaly, there is a more serious problem: you are breaking the >>> rule of package orthogonality; (no individual file should be delivered >>> by more than one package). In introducing this pair of packages, you >>> are creating conflicts with the existing mingwrt and w32api packages; >>> I'm afraid that current mingw-get just isn't equipped to handle any such >>> scenario. >> >> Suggestions? > > The technique I've used for mingw-get-gui is an option, (overriding the > single catalogue file, for those who opt in). Another would be to offer > a complete modified catalogue set, from a distinctly different host URL, > with opt in by adjustment of the repository configuration in profile.xml > > Other than these, I don't think there's any alternative, without > significant further development of mingw-get; (I eventually plan to add > a policy configuration option, which would allow users to opt in or out > of upgrades to non-stable classified releases, but that's still a long > way off). How about: rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma or mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma Would either of these produce the result I'm looking for? Which is better? With the second the profile.xml file would need to be adjusted by the user to add the directory location for the rc_mingw32 system but the package name is the same. With the first the user has a new package name. Should it rather be a mix of both: rc_mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma? -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-03-04 14:21:55
|
On Sat, Mar 2, 2013 at 11:41 AM, Earnie Boyd wrote:
>
> How about:
>
> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma
>
This one works well.
~~~~~~
diff --git a/mingw32/mingw32-runtime.xml b/mingw32/mingw32-runtime.xml
index 59a92d3..2b4b1f8 100644
--- a/mingw32/mingw32-runtime.xml
+++ b/mingw32/mingw32-runtime.xml
@@ -72,6 +72,81 @@
</component>
</package>
+ <package name="mingw32-rc_mingwrt" alias="rc_mingwrt">
+ <affiliate group="MinGW Compiler Suite" />
+ <affiliate group="MinGW Standard Libraries" />
+ <description lang="en" title="The MinGW Runtime Library API">
+ <paragraph>
+ CAUTION: This is a release candidate. This release candidate has an
+ ABI change that may cause you to need to recompile and link your
+ libraries.
+ </paragraph>
+ <paragraph>
+ This package provides the header files, system object modules,
+ dynamic link libraries, import libraries and static libraries
+ which constitute the standard MinGW Runtime API.
+ </paragraph>
+ <paragraph>
+ This is a required component of the MinGW Compiler Suite.
+ </paragraph>
+ </description>
+
+ <source tarname="rc_mingwrt-4.0-1-mingw32-rc-1-src.tar.lzma" />
+ <license tarname="rc_mingwrt-4.0-1-mingw32-rc-1-lic.tar.lzma" />
+
+ <component class="dev">
+ <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma" />
+ </component>
+
+ <component class="dll">
+ <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-dll.tar.lzma" />
+ </component>
+
+ <component class="doc">
+ <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-doc.tar.lzma" />
+ </component>
+
+ <component class="lic">
+ <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-lic.tar.lzma" />
+ </component>
+ </package>
+
+ <package name="mingw32-rc_w32api">
+ <affiliate group="MinGW Compiler Suite" />
+ <affiliate group="MinGW Standard Libraries" />
+ <description lang="en" title="The MinGW API for 32-Bit MS-Windows">
+ <paragraph>
+ CAUTION: This is a release candidate. This release candidate has an
+ ABI change that may cause you to need to recompile and link your
+ libraries.
+ </paragraph>
+ <paragraph>
+ This package provides the header files, and import libraries
+ constituting a standard API for the development of applications
+ which utilise the capabilities of the 32-bit MS-Windows system
+ dynamic link libraries.
+ </paragraph>
+ <paragraph>
+ This is a required component of the MinGW Compiler Suite.
+ </paragraph>
+ </description>
+
+ <source tarname="rc_w32api-4.0-1-mingw32-rc-1-src.tar.lzma" />
+ <licence tarname="rc_w32api-4.0-1-mingw32-rc-1-lic.tar.lzma" />
+
+ <component class="dev">
+ <release tarname="rc_w32api-4.0-1-mingw32-rc-1-dev.tar.lzma" />
+ </component>
+
+ <component class="doc">
+ <release tarname="rc_w32api-4.0-1-mingw32-rc-1-doc.tar.lzma" />
+ </component>
+
+ <component class="lic">
+ <release tarname="rc_w32api-4.0-1-mingw32-rc-1-lic.tar.lzma" />
+ </component>
+ </package>
+
</package-collection>
</software-distribution>
<!-- vim: set nocompatible expandtab fileformat=unix textwidth=80
tabstop=2 shiftwidth=2: -->
~~~~~~
The instructions to the user would suggest how to remove rc_mingwrt
and rc_w32api and then --reinstall mingwrt and w32api.
If this is reasonable then I'll upload the files soon. I'll merge
4.0-dev to master and then tag a 4.0-rc1 release.
Should we be tagging the mingw-dist for our releases? Something like
wsl-4.0-rc1?
--
Earnie
-- https://sites.google.com/site/earnieboyd
|
|
From: Keith M. <kei...@us...> - 2013-03-04 19:13:38
|
On 02/03/13 16:41, Earnie Boyd wrote:
> How about:
>
> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma
>
> or
>
> mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma
>
> Would either of these produce the result I'm looking for?
Either may, but the former is unacceptable.
> Which is better?
The latter, but it's far from ideal; (I'm not even certain that it will
work reliably).
> With the second the profile.xml file would need to be adjusted by the
> user to add the directory location for the rc_mingw32 system but the
> package name is the same.
Which may be awkward for the user, but at least it doesn't exhibit the
failing of...
> With the first the user has a new package name.
...a new, and therefore independent package, which deliberately causes
conflict with the existing mingwrt-*-mingw32-...; Chuck invested a lot
of effort into convincing me that this is ultimately unworkable.
> Should it rather be a mix of both:
> rc_mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma?
No. Definitely not. What about the following (untested) alternative?
* In its own XML catalogue, create a definition for a wsl-candidate
package; this will be a dummy package, delivering only a replacement for
var/lib/mingw-get/data/mingw32-runtime.xml itself, (as payload of
wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz, say).
* Add a reference for this new catalogue to mingw32-package-list.xml
* Publish the new catalogue, and the updated package list.
* Make a private local copy of mingw32-runtime.xml, (perhaps within a
private local git branch of mingw-dist).
* Add your "release" specs for mingwrt-4.0 and w32api-4.0, as if you
were making a formal release; DO NOT PUBLISH THIS!
* In your working directory, (taking care not to destroy anything you
really want to keep):
rm -rf var
mkdir -p var/lib/mingw-get/data
sed s/@YYYYMMDDNN@/ZZZZZZZZZZ/ mingw32-runtime.xml \
> var/lib/mingw-get/data/mingw32-runtime.xml
tar cf - var | xz -c > wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz
* Publish the resultant tarball.
Now, users may opt in to testing your candidate, by running:
mingw-get update
mingw-get install mingw32-wsl-candidate
mingw-get upgrade mingw32-mingwrt mingw32-w32api
and may opt out again, by:
mingw-get remove mingw32-wsl-candidate
mingw-get upgrade --reinstall mingw32-mingwrt mingw32-w32api
(with the caveat, for GUI users, that they must use the CLI to perform
these operations).
--
Regards,
Keith.
|
|
From: Earnie B. <ea...@us...> - 2013-03-04 19:44:46
|
On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: > On 02/03/13 16:41, Earnie Boyd wrote: >> How about: >> >> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma >> >> or >> >> mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma >> >> Would either of these produce the result I'm looking for? > > Either may, but the former is unacceptable. > Why is it unacceptable. I tested it and it actually works well. mingw-get install mingw32-rc_mingwrt mingw-get install mingw32-rc_w32api I removed the alias for the rc package so you must specify mingw32. Of course the DB thinks both mingwrt and rc_mingwrt are installed but that is OK. To reverse back to the latest versions production release versions you would simply do mingw-get remove rc_mingwrt mingw-get remove rc_w32api mingw-get install --reinstall mingwrt mingw-get install --reinstall w32api >> Which is better? > > The latter, but it's far from ideal; (I'm not even certain that it will > work reliably). > >> With the second the profile.xml file would need to be adjusted by the >> user to add the directory location for the rc_mingw32 system but the >> package name is the same. > > Which may be awkward for the user, but at least it doesn't exhibit the > failing of... > >> With the first the user has a new package name. > > ...a new, and therefore independent package, which deliberately causes > conflict with the existing mingwrt-*-mingw32-...; Chuck invested a lot > of effort into convincing me that this is ultimately unworkable. > >> Should it rather be a mix of both: >> rc_mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma? > > No. Definitely not. What about the following (untested) alternative? > > * In its own XML catalogue, create a definition for a wsl-candidate > package; this will be a dummy package, delivering only a replacement for > var/lib/mingw-get/data/mingw32-runtime.xml itself, (as payload of > wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz, say). > I'll give this some thought and testing. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Keith M. <kei...@us...> - 2013-03-04 20:25:24
|
On 04/03/13 19:44, Earnie Boyd wrote: > On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: >> On 02/03/13 16:41, Earnie Boyd wrote: >>> How about: >>> >>> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma >>> >>> or >>> >>> mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma >>> >>> Would either of these produce the result I'm looking for? >> >> Either may, but the former is unacceptable. > > Why is it unacceptable. I tested it and it actually works well. It may *appear* to work, but you now have two disparate and conflicting packages, each claiming to own (at least a subset of) the same payload of installed files. Install one, or the other, and things will surely appear to work out okay. Even install both together, and it may still seem to work. Now, with both installed, remove just one, and you'll break the other. You are creating a scenario in which mingw-get must lose track of what files have been installed by which package; IOW, a recipe for confusion and potential problems down the line. -- Regards, Keith. |
|
From: Keith M. <kei...@us...> - 2013-03-04 20:47:08
|
On 04/03/13 14:21, Earnie Boyd wrote: > Should we be tagging the mingw-dist for our releases? Something like > wsl-4.0-rc1? I don't think so. You're going to drown in a swamp of tags, for every package in the MinGW/MSYS universe. IMO, the only valid reason for tagging here would be to reflect the state of modifications to mingw-dist's own build infrastructure. -- Regards, Keith. |
|
From: Earnie B. <ea...@us...> - 2013-03-05 14:23:42
|
On Mon, Mar 4, 2013 at 3:46 PM, Keith Marshall wrote: > On 04/03/13 14:21, Earnie Boyd wrote: >> Should we be tagging the mingw-dist for our releases? Something like >> wsl-4.0-rc1? > > I don't think so. You're going to drown in a swamp of tags, for every > package in the MinGW/MSYS universe. > > IMO, the only valid reason for tagging here would be to reflect the > state of modifications to mingw-dist's own build infrastructure. Makes sense to me; I'll agree with this. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-03-05 15:08:05
|
On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: > What about the following (untested) alternative? > > * In its own XML catalogue, create a definition for a wsl-candidate > package; this will be a dummy package, delivering only a replacement for > var/lib/mingw-get/data/mingw32-runtime.xml itself, (as payload of > wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz, say). > > * Add a reference for this new catalogue to mingw32-package-list.xml > > * Publish the new catalogue, and the updated package list. > > * Make a private local copy of mingw32-runtime.xml, (perhaps within a > private local git branch of mingw-dist). > > * Add your "release" specs for mingwrt-4.0 and w32api-4.0, as if you > were making a formal release; DO NOT PUBLISH THIS! > > * In your working directory, (taking care not to destroy anything you > really want to keep): > > rm -rf var > mkdir -p var/lib/mingw-get/data > sed s/@YYYYMMDDNN@/ZZZZZZZZZZ/ mingw32-runtime.xml \ > > var/lib/mingw-get/data/mingw32-runtime.xml > tar cf - var | xz -c > wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz > > * Publish the resultant tarball. > > Now, users may opt in to testing your candidate, by running: > > mingw-get update > mingw-get install mingw32-wsl-candidate > mingw-get upgrade mingw32-mingwrt mingw32-w32api > > and may opt out again, by: > > mingw-get remove mingw32-wsl-candidate > mingw-get upgrade --reinstall mingw32-mingwrt mingw32-w32api I'm not seeing how this scenario is going to work correctly. The modified mingw32-runtime.xml will still be existent and the upgrade --reinstall will install the RC. On Mon, Mar 4, 2013 at 3:25 PM, Keith Marshall wrote: > On 04/03/13 19:44, Earnie Boyd wrote: >> On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: >>> On 02/03/13 16:41, Earnie Boyd wrote: >>>> How about: >>>> >>>> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma >>>> >>>> or >>>> >>>> mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma >>>> >>>> Would either of these produce the result I'm looking for? >>> >>> Either may, but the former is unacceptable. >> >> Why is it unacceptable. I tested it and it actually works well. > > It may *appear* to work, but you now have two disparate and conflicting > packages, each claiming to own (at least a subset of) the same payload > of installed files. Install one, or the other, and things will surely > appear to work out okay. Even install both together, and it may still > seem to work. Now, with both installed, remove just one, and you'll > break the other. > > You are creating a scenario in which mingw-get must lose track of what > files have been installed by which package; IOW, a recipe for confusion > and potential problems down the line. > I don't see mingw-get losing track and I don't see how the alternate scenario you've given is that much different. There are two separate packages (mingwrt and rc_mingwrt), that have similar file sets. Yes, if you remove one of those packages then you must reinstall one or the other and that is a caveat for the user using the release and is easily corrected by the user; but this is the case with your alternate scenario as well. With my design the user would mingw-get update mingw-get install mingw32-rc_mingwrt mingw32-rc_w32api to use the RC and then to fall back to the previous version would simply do mingw-get remove mingw32-rc_mingwrt mingw32-rc_w32api mingw-get install --reinstall mingwrt w32api I think the msys-core and msys-coreutils scenario is even more confusing than what I'm proposing. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-03-05 17:42:24
|
On Tue, Mar 5, 2013 at 10:07 AM, Earnie Boyd wrote: > On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: >> What about the following (untested) alternative? >> >> * In its own XML catalogue, create a definition for a wsl-candidate >> package; this will be a dummy package, delivering only a replacement for >> var/lib/mingw-get/data/mingw32-runtime.xml itself, (as payload of >> wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz, say). >> >> * Add a reference for this new catalogue to mingw32-package-list.xml >> >> * Publish the new catalogue, and the updated package list. >> >> * Make a private local copy of mingw32-runtime.xml, (perhaps within a >> private local git branch of mingw-dist). >> >> * Add your "release" specs for mingwrt-4.0 and w32api-4.0, as if you >> were making a formal release; DO NOT PUBLISH THIS! >> >> * In your working directory, (taking care not to destroy anything you >> really want to keep): >> >> rm -rf var >> mkdir -p var/lib/mingw-get/data >> sed s/@YYYYMMDDNN@/ZZZZZZZZZZ/ mingw32-runtime.xml \ >> > var/lib/mingw-get/data/mingw32-runtime.xml >> tar cf - var | xz -c > wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz >> >> * Publish the resultant tarball. >> >> Now, users may opt in to testing your candidate, by running: >> >> mingw-get update >> mingw-get install mingw32-wsl-candidate >> mingw-get upgrade mingw32-mingwrt mingw32-w32api >> >> and may opt out again, by: >> >> mingw-get remove mingw32-wsl-candidate >> mingw-get upgrade --reinstall mingw32-mingwrt mingw32-w32api > > I'm not seeing how this scenario is going to work correctly. The > modified mingw32-runtime.xml will still be existent and the upgrade > --reinstall will install the RC. > > > On Mon, Mar 4, 2013 at 3:25 PM, Keith Marshall wrote: >> On 04/03/13 19:44, Earnie Boyd wrote: >>> On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: >>>> On 02/03/13 16:41, Earnie Boyd wrote: >>>>> How about: >>>>> >>>>> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma >>>>> >>>>> or >>>>> >>>>> mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma >>>>> >>>>> Would either of these produce the result I'm looking for? >>>> >>>> Either may, but the former is unacceptable. >>> >>> Why is it unacceptable. I tested it and it actually works well. >> >> It may *appear* to work, but you now have two disparate and conflicting >> packages, each claiming to own (at least a subset of) the same payload >> of installed files. Install one, or the other, and things will surely >> appear to work out okay. Even install both together, and it may still >> seem to work. Now, with both installed, remove just one, and you'll >> break the other. >> >> You are creating a scenario in which mingw-get must lose track of what >> files have been installed by which package; IOW, a recipe for confusion >> and potential problems down the line. >> > > I don't see mingw-get losing track and I don't see how the alternate > scenario you've given is that much different. There are two separate > packages (mingwrt and rc_mingwrt), that have similar file sets. Yes, > if you remove one of those packages then you must reinstall one or the > other and that is a caveat for the user using the release and is > easily corrected by the user; but this is the case with your alternate > scenario as well. > > With my design the user would > > mingw-get update > mingw-get install mingw32-rc_mingwrt mingw32-rc_w32api > > to use the RC and then to fall back to the previous version would simply do > > mingw-get remove mingw32-rc_mingwrt mingw32-rc_w32api > mingw-get install --reinstall mingwrt w32api > > I think the msys-core and msys-coreutils scenario is even more > confusing than what I'm proposing. However, I understand that I should put the package meta data in its own file. Otherwise, it would have to remain in mingw32-runtime.xml. I could name that mingw32-wsl-candidate.xml. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-03-11 18:49:09
|
On Tue, Mar 5, 2013 at 12:42 PM, Earnie Boyd wrote: > On Tue, Mar 5, 2013 at 10:07 AM, Earnie Boyd wrote: >> On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: >>> What about the following (untested) alternative? >>> >>> * In its own XML catalogue, create a definition for a wsl-candidate >>> package; this will be a dummy package, delivering only a replacement for >>> var/lib/mingw-get/data/mingw32-runtime.xml itself, (as payload of >>> wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz, say). >>> >>> * Add a reference for this new catalogue to mingw32-package-list.xml >>> >>> * Publish the new catalogue, and the updated package list. >>> >>> * Make a private local copy of mingw32-runtime.xml, (perhaps within a >>> private local git branch of mingw-dist). >>> >>> * Add your "release" specs for mingwrt-4.0 and w32api-4.0, as if you >>> were making a formal release; DO NOT PUBLISH THIS! >>> >>> * In your working directory, (taking care not to destroy anything you >>> really want to keep): >>> >>> rm -rf var >>> mkdir -p var/lib/mingw-get/data >>> sed s/@YYYYMMDDNN@/ZZZZZZZZZZ/ mingw32-runtime.xml \ >>> > var/lib/mingw-get/data/mingw32-runtime.xml >>> tar cf - var | xz -c > wsl-candidate-4.0-1-mingw32-rc-1-xml.tar.xz >>> >>> * Publish the resultant tarball. >>> >>> Now, users may opt in to testing your candidate, by running: >>> >>> mingw-get update >>> mingw-get install mingw32-wsl-candidate >>> mingw-get upgrade mingw32-mingwrt mingw32-w32api >>> >>> and may opt out again, by: >>> >>> mingw-get remove mingw32-wsl-candidate >>> mingw-get upgrade --reinstall mingw32-mingwrt mingw32-w32api >> >> I'm not seeing how this scenario is going to work correctly. The >> modified mingw32-runtime.xml will still be existent and the upgrade >> --reinstall will install the RC. >> >> >> On Mon, Mar 4, 2013 at 3:25 PM, Keith Marshall wrote: >>> On 04/03/13 19:44, Earnie Boyd wrote: >>>> On Mon, Mar 4, 2013 at 12:13 PM, Keith Marshall wrote: >>>>> On 02/03/13 16:41, Earnie Boyd wrote: >>>>>> How about: >>>>>> >>>>>> rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma >>>>>> >>>>>> or >>>>>> >>>>>> mingwrt-4.0-1-rc_mingw32-rc-1-dev.tar.lzma >>>>>> >>>>>> Would either of these produce the result I'm looking for? >>>>> >>>>> Either may, but the former is unacceptable. >>>> >>>> Why is it unacceptable. I tested it and it actually works well. >>> >>> It may *appear* to work, but you now have two disparate and conflicting >>> packages, each claiming to own (at least a subset of) the same payload >>> of installed files. Install one, or the other, and things will surely >>> appear to work out okay. Even install both together, and it may still >>> seem to work. Now, with both installed, remove just one, and you'll >>> break the other. >>> >>> You are creating a scenario in which mingw-get must lose track of what >>> files have been installed by which package; IOW, a recipe for confusion >>> and potential problems down the line. >>> >> >> I don't see mingw-get losing track and I don't see how the alternate >> scenario you've given is that much different. There are two separate >> packages (mingwrt and rc_mingwrt), that have similar file sets. Yes, >> if you remove one of those packages then you must reinstall one or the >> other and that is a caveat for the user using the release and is >> easily corrected by the user; but this is the case with your alternate >> scenario as well. >> >> With my design the user would >> >> mingw-get update >> mingw-get install mingw32-rc_mingwrt mingw32-rc_w32api >> >> to use the RC and then to fall back to the previous version would simply do >> >> mingw-get remove mingw32-rc_mingwrt mingw32-rc_w32api >> mingw-get install --reinstall mingwrt w32api >> >> I think the msys-core and msys-coreutils scenario is even more >> confusing than what I'm proposing. > > However, I understand that I should put the package meta data in its > own file. Otherwise, it would have to remain in mingw32-runtime.xml. > I could name that mingw32-wsl-candidate.xml. Ping. For this I have: ~~~~~~ diff --git a/mingw32/issue.log b/mingw32/issue.log index 840a10a..545b4bf 100755 --- a/mingw32/issue.log +++ b/mingw32/issue.log @@ -50,11 +50,12 @@ cd33ad74b608bce33ea297801253e6efbafce27c 2012073100 mingw32-mingw-utils.xml d31c39c6584fde6d4b9ddafbca913509b32a1dfc 2012073100 mingw32-mpc.xml 99995a8e17659b6514f71ae2b17bbbcd8eb4c0a9 2012073100 mingw32-mpfr.xml - 250646540a24a6b329cebb13d4b71aa195fda8b2 2012040500 mingw32-package-list.xml + 983af8ad24a6f97da867784dfeeecc6661d54d88 2013030500 mingw32-package-list.xml 40c94ac07003ac8f36558a8c33581a748ec03e3a 2012073100 mingw32-pexports.xml cdb2a4dbedfc9f2cdfc92340f6f9b12da061c0d9 2012073100 mingw32-popt.xml 9399cb6c2efd8fd907c42a278a6f41bbde9e440c 2011091400 mingw32-pthreads-w32.xml 428964289b3509293a13c9394199b5e2d4887c3e 2012063001 mingw32-runtime.xml + 497ad4f2d3414802b7751ef8c77b87122d95e5c2 2013030500 mingw32-wsl-candidate.xml 247a02890f109a5fe4996fde4af9d576dca3cd1e 2012073100 mingw32-xz.xml 4a2e1515655331483b8ddc898b2405fb89401d73 2012073100 mingw32-zlib.xml # diff --git a/mingw32/mingw32-package-list.xml b/mingw32/mingw32-package-list.xml index b176ad2..c997384 100644 --- a/mingw32/mingw32-package-list.xml +++ b/mingw32/mingw32-package-list.xml @@ -47,6 +47,7 @@ <package-list catalogue="mingw32-popt" /> <package-list catalogue="mingw32-pthreads-w32" /> <package-list catalogue="mingw32-runtime" /> + <package-list catalogue="mingw32-wsl-candidate" /> <package-list catalogue="mingw32-xz" /> <package-list catalogue="mingw32-zlib" /> diff --git a/mingw32/mingw32-wsl-candidate.xml b/mingw32/mingw32-wsl-candidate.xml new file mode 100644 index 0000000..4ad934e --- /dev/null +++ b/mingw32/mingw32-wsl-candidate.xml @@ -0,0 +1,92 @@ +<?xml version="1.0" encoding="UTF-8" standalone="yes"?> +<software-distribution project="MinGW" home="http://www.mingw.org" issue="@YYYYMMDDNN@"> + + <!-- File: mingw32-runtime.xml ~~ mingw-get package description for MinGW API --> + + <package-collection subsystem="mingw32"> + <download-host uri="http://prdownloads.sourceforge.net/mingw/%F?download" /> + + <!-- Provides the package descriptions for each of the two primary --> + <!-- packages, which comprise the standard MinGW Runtime Library API, --> + <!-- namely mingwrt and w32api. --> + + <package name="mingw32-rc_mingwrt" alias="rc_mingwrt"> + <affiliate group="MinGW Compiler Suite" /> + <affiliate group="MinGW Standard Libraries" /> + <description lang="en" title="The MinGW Runtime Library API"> + <paragraph> + CAUTION: This is a release candidate. This release candidate has an + ABI change that may cause you to need to recompile and link your + libraries. When you remove this package you will need to reinstall + the previous mingwrt version. + </paragraph> + <paragraph> + This package provides the header files, system object modules, + dynamic link libraries, import libraries and static libraries + which constitute the standard MinGW Runtime API. + </paragraph> + <paragraph> + This is a required component of the MinGW Compiler Suite. + </paragraph> + </description> + + <source tarname="rc_mingwrt-4.0-1-mingw32-rc-1-src.tar.lzma" /> + <license tarname="rc_mingwrt-4.0-1-mingw32-rc-1-lic.tar.lzma" /> + + <component class="dev"> + <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-dev.tar.lzma" /> + </component> + + <component class="dll"> + <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-dll.tar.lzma" /> + </component> + + <component class="doc"> + <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-doc.tar.lzma" /> + </component> + + <component class="lic"> + <release tarname="rc_mingwrt-4.0-1-mingw32-rc-1-lic.tar.lzma" /> + </component> + </package> + + <package name="mingw32-rc_w32api"> + <affiliate group="MinGW Compiler Suite" /> + <affiliate group="MinGW Standard Libraries" /> + <description lang="en" title="The MinGW API for 32-Bit MS-Windows"> + <paragraph> + CAUTION: This is a release candidate. This release candidate has an + ABI change that may cause you to need to recompile and link your + libraries. When you remove this package you will need to reinstall + the previous w32api version. + </paragraph> + <paragraph> + This package provides the header files, and import libraries + constituting a standard API for the development of applications + which utilise the capabilities of the 32-bit MS-Windows system + dynamic link libraries. + </paragraph> + <paragraph> + This is a required component of the MinGW Compiler Suite. + </paragraph> + </description> + + <source tarname="rc_w32api-4.0-1-mingw32-rc-1-src.tar.lzma" /> + <licence tarname="rc_w32api-4.0-1-mingw32-rc-1-lic.tar.lzma" /> + + <component class="dev"> + <release tarname="rc_w32api-4.0-1-mingw32-rc-1-dev.tar.lzma" /> + </component> + + <component class="doc"> + <release tarname="rc_w32api-4.0-1-mingw32-rc-1-doc.tar.lzma" /> + </component> + + <component class="lic"> + <release tarname="rc_w32api-4.0-1-mingw32-rc-1-lic.tar.lzma" /> + </component> + </package> + + </package-collection> +</software-distribution> +<!-- vim: set nocompatible expandtab fileformat=unix textwidth=80 tabstop=2 shiftwidth=2: --> ~~~~~~ -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Keith M. <kei...@us...> - 2013-03-11 23:15:22
|
On 11/03/13 18:49, Earnie Boyd wrote: >> However, I understand that I should put the package meta data in its >> >own file. Otherwise, it would have to remain in mingw32-runtime.xml. >> >I could name that mingw32-wsl-candidate.xml. > Ping. Separation of the package meta-data isn't the issue; the overlap in package content is. You are advocating that users who would like to test your release candidate should mingw-get remove the original package, then install a *different* package instead. That's going to break the dependency chain for GCC, behind mingw-get's back. If a user, having followed your bogus installation path, subsequently touches GCC again, with mingw-get, who can tell what sort of mess is likely to ensue? You are proposing to violate the packaging rules we agreed, in the early days of mingw-get's development; (stated mathematically, in terms of set theory, that policy was that the intersection of the sets of files to be installed by any two distinct packages shall be the empty set). I consider such policy violation to be unacceptable, and have stated this previously. You may disagree, to the extent that the declaration of unacceptability is too strong, but the course you propose is definitely unsafe [*]. The better way to handle this is to publish the package upgrades, as if they were formal releases of the existing mingwrt and w32api packages, but to hold back the catalogue updates, while making previews of those catalogue updates available to users who wish to test the candidate releases. The alternative technique which I suggested does just that, by installing a preview catalogue in place of the formally published version, while setting its issue serialisation attribute to lock it against "mingw-get update", without interfering in any way with mingw-get's package dependency chains. If, having installed that preview catalogue, a user wishes to revert to the official release state, they simply mingw-get remove the preview catalogue, and mingw-get will automatically replace it with the formally published version, the next time it is invoked. IMO, that is a much safer way to achieve your desired effect. [*] Furthermore, when I eventually get reverse dependency look-up working for mingw-get remove, your proposed technique will cease to be an option; the removal of the pre-requisite package will be prohibited. -- Regards, Keith. |
|
From: Earnie B. <ea...@us...> - 2013-03-12 15:07:40
|
On Mon, Mar 11, 2013 at 7:15 PM, Keith Marshall wrote: > On 11/03/13 18:49, Earnie Boyd wrote: >>> However, I understand that I should put the package meta data in its >>> >own file. Otherwise, it would have to remain in mingw32-runtime.xml. >>> >I could name that mingw32-wsl-candidate.xml. >> Ping. > > Separation of the package meta-data isn't the issue; the overlap in > package content is. > > You are advocating that users who would like to test your release > candidate should mingw-get remove the original package, then install a > *different* package instead. Uh, no I'm not. mingw-get install mingw32-rc_mingwrt mingw32-rc_w32api This doesn't remove the existing package from mingw-get. It installs an alternate set of the same files. > That's going to break the dependency chain > for GCC, behind mingw-get's back. No, it doesn't, the dependency is still intact. > If a user, having followed your bogus > installation path, subsequently touches GCC again, with mingw-get, who > can tell what sort of mess is likely to ensue? > Touches how? mingw-get install --reinstall gcc will only reinstall ~~~~~~ reinstall: gcc-4.7.2-1-mingw32-lic.tar.lzma installing gcc-4.7.2-1-mingw32-lic.tar.lzma reinstall: gcc-core-4.7.2-1-mingw32-bin.tar.lzma installing gcc-core-4.7.2-1-mingw32-bin.tar.lzma reinstall: gcc-4.7.2-1-mingw32-doc.tar.lzma installing gcc-4.7.2-1-mingw32-doc.tar.lzma reinstall: gcc-4.7.2-1-mingw32-lang.tar.lzma removing release gcc-4.7.2-1-mingw32-lang.tar.lzma installing gcc-4.7.2-1-mingw32-lang.tar.lzma ~~~~~~ The only possible collision is that the files from mingw32-mingwrt and mingw32-w32api are installed again over top of the mingw32-rc_mingwrt and mingw32-rc_w32api packages. That isn't a hell raising issue. > You are proposing to violate the packaging rules we agreed, in the early > days of mingw-get's development; (stated mathematically, in terms of set > theory, that policy was that the intersection of the sets of files to be > installed by any two distinct packages shall be the empty set). The package names are different. The files are named for the package they represent. The contents of the files happen to be similar. There is no violation of rules. > I > consider such policy violation to be unacceptable, and have stated this > previously. You may disagree, to the extent that the declaration of > unacceptability is too strong, but the course you propose is definitely > unsafe [*]. > I don't see this as unsafe, I've tested the methods. The potential hazard is the end user removes one or the other package and thus leaves the files associated with that package removed. Easily correctable by a --reinstall of the package he wants to keep. There is no harm to the mingw-get data regardless of the end user action. > The better way to handle this is to publish the package upgrades, as if > they were formal releases of the existing mingwrt and w32api packages, > but to hold back the catalogue updates, while making previews of those > catalogue updates available to users who wish to test the candidate > releases. The alternative technique which I suggested does just that, > by installing a preview catalogue in place of the formally published > version, while setting its issue serialisation attribute to lock it > against "mingw-get update", without interfering in any way with > mingw-get's package dependency chains. > And I stated that I didn't see how your alternate method can work as you stated. > If, having installed that preview catalogue, a user wishes to revert to > the official release state, they simply mingw-get remove the preview > catalogue, and mingw-get will automatically replace it with the formally > published version, the next time it is invoked. > And so it is with my method as well. ~~~~~~ mingw-get remove mingw32-rc_mingwrt mingw32-rc_w32api mingw-get install --reinstall mingw-32-mingwrt mingw32-w32api ~~~~~~ How does this cause any headache with your [*] bullet? > IMO, that is a much safer way to achieve your desired effect. > I still do not see the benefit in safety or workability in your procedure. > [*] Furthermore, when I eventually get reverse dependency look-up > working for mingw-get remove, your proposed technique will cease to be > an option; the removal of the pre-requisite package will be prohibited. > As stated already, the removal of mingw32-mingwrt and mingw32-w32api is not a requirement nor published method. Those prerequisite packages still exist as far as mingw-get is concerned; I've published different packages. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Earnie B. <ea...@us...> - 2013-03-14 15:55:22
|
Keith does my retort satisfy your concerns? On Tue, Mar 12, 2013 at 11:07 AM, Earnie Boyd wrote: > On Mon, Mar 11, 2013 at 7:15 PM, Keith Marshall wrote: >> On 11/03/13 18:49, Earnie Boyd wrote: >>>> However, I understand that I should put the package meta data in its >>>> >own file. Otherwise, it would have to remain in mingw32-runtime.xml. >>>> >I could name that mingw32-wsl-candidate.xml. >>> Ping. >> >> Separation of the package meta-data isn't the issue; the overlap in >> package content is. >> >> You are advocating that users who would like to test your release >> candidate should mingw-get remove the original package, then install a >> *different* package instead. > > Uh, no I'm not. > mingw-get install mingw32-rc_mingwrt mingw32-rc_w32api > This doesn't remove the existing package from mingw-get. It installs > an alternate set of the same files. > >> That's going to break the dependency chain >> for GCC, behind mingw-get's back. > > No, it doesn't, the dependency is still intact. > >> If a user, having followed your bogus >> installation path, subsequently touches GCC again, with mingw-get, who >> can tell what sort of mess is likely to ensue? >> > > Touches how? > mingw-get install --reinstall gcc > will only reinstall > ~~~~~~ > reinstall: gcc-4.7.2-1-mingw32-lic.tar.lzma > installing gcc-4.7.2-1-mingw32-lic.tar.lzma > reinstall: gcc-core-4.7.2-1-mingw32-bin.tar.lzma > installing gcc-core-4.7.2-1-mingw32-bin.tar.lzma > reinstall: gcc-4.7.2-1-mingw32-doc.tar.lzma > installing gcc-4.7.2-1-mingw32-doc.tar.lzma > reinstall: gcc-4.7.2-1-mingw32-lang.tar.lzma > removing release gcc-4.7.2-1-mingw32-lang.tar.lzma > installing gcc-4.7.2-1-mingw32-lang.tar.lzma > ~~~~~~ > The only possible collision is that the files from mingw32-mingwrt and > mingw32-w32api are installed again over top of the mingw32-rc_mingwrt > and mingw32-rc_w32api packages. That isn't a hell raising issue. > >> You are proposing to violate the packaging rules we agreed, in the early >> days of mingw-get's development; (stated mathematically, in terms of set >> theory, that policy was that the intersection of the sets of files to be >> installed by any two distinct packages shall be the empty set). > > The package names are different. The files are named for the package > they represent. The contents of the files happen to be similar. > There is no violation of rules. > >> I >> consider such policy violation to be unacceptable, and have stated this >> previously. You may disagree, to the extent that the declaration of >> unacceptability is too strong, but the course you propose is definitely >> unsafe [*]. >> > > I don't see this as unsafe, I've tested the methods. The potential > hazard is the end user removes one or the other package and thus > leaves the files associated with that package removed. Easily > correctable by a --reinstall of the package he wants to keep. There > is no harm to the mingw-get data regardless of the end user action. > >> The better way to handle this is to publish the package upgrades, as if >> they were formal releases of the existing mingwrt and w32api packages, >> but to hold back the catalogue updates, while making previews of those >> catalogue updates available to users who wish to test the candidate >> releases. The alternative technique which I suggested does just that, >> by installing a preview catalogue in place of the formally published >> version, while setting its issue serialisation attribute to lock it >> against "mingw-get update", without interfering in any way with >> mingw-get's package dependency chains. >> > > And I stated that I didn't see how your alternate method can work as you stated. > >> If, having installed that preview catalogue, a user wishes to revert to >> the official release state, they simply mingw-get remove the preview >> catalogue, and mingw-get will automatically replace it with the formally >> published version, the next time it is invoked. >> > > And so it is with my method as well. > ~~~~~~ > mingw-get remove mingw32-rc_mingwrt mingw32-rc_w32api > mingw-get install --reinstall mingw-32-mingwrt mingw32-w32api > ~~~~~~ > How does this cause any headache with your [*] bullet? > >> IMO, that is a much safer way to achieve your desired effect. >> > > I still do not see the benefit in safety or workability in your procedure. > >> [*] Furthermore, when I eventually get reverse dependency look-up >> working for mingw-get remove, your proposed technique will cease to be >> an option; the removal of the pre-requisite package will be prohibited. >> > > As stated already, the removal of mingw32-mingwrt and mingw32-w32api > is not a requirement nor published method. > Those prerequisite packages still exist as far as mingw-get is > concerned; I've published different packages. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Keith M. <kei...@us...> - 2013-03-14 16:57:05
|
On 14 March 2013 15:55, Earnie Boyd wrote: > Keith does my retort satisfy your concerns? > I still have some; in particular, I still think it is a really bad idea to have two packages, with differing names as you propose, which deliver (at least a subset of) identically named files. (FWIW, and just like you, apparently, I was not of this conviction initially, but Chuck convinced me; as I have progressed the development of mingw-get, my conviction has increased). Meanwhile, I have been exploring my own proposed alternative method of delivery. It also works well, and it has the benefit of avoiding the issue of overlapping package content, entirely. I know you're itching to get a candidate out, but I'll need to get back to you; I'll aim to do that by end of play tomorrow. -- Regards, Keith. |
|
From: Earnie B. <ea...@us...> - 2013-03-14 17:41:58
|
On Thu, Mar 14, 2013 at 12:56 PM, Keith Marshall wrote: > On 14 March 2013 15:55, Earnie Boyd wrote: >> >> Keith does my retort satisfy your concerns? > > > I still have some; in particular, I still think it is a really bad > idea to have two packages, with differing names as you propose, which > deliver (at least a subset of) identically named files. (FWIW, and > just like you, apparently, I was not of this conviction initially, but > Chuck convinced me; as I have progressed the development of mingw-get, > my conviction has increased). > I think this is better than what we have with msys-core and msys-coreutils where the two packages deliver the same packaged set of files and hidden from the user is a potential to remove some important parts of MSYS because he is removing an additional package. At least with my scenario the user is aware up front of the possibility of loosing files on removal of the package. > Meanwhile, I have been exploring my own proposed alternative method of > delivery. It also works well, and it has the benefit of avoiding the > issue of overlapping package content, entirely. > I'm looking forward to this but there will always be overlapping package content regardless of how it is delivered. > I know you're itching to get a candidate out, but I'll need to get back > to you; I'll aim to do that by end of play tomorrow. > I hope the "play" has lots of action scenes. ;p -- Earnie -- https://sites.google.com/site/earnieboyd |
Thanks for helping keep SourceForge clean.
X