Re: Our GCC-4.8 is broken

On 22/12/13 00:44, Cesar Strauss wrote:
> On 12/18/2013 09:52 AM, Keith Marshall wrote:
>> In the short term, I'm inclined to suggest rolling back to GCC-4.7, as
>> our default offering, and ripping all of the broken packages out of the
>> on-line catalogue.
> 
> I agree, this would give us time to solve the bugs and to redo the
> packaging carefully.
> 
> How would this downgrade be implemented?

Right now, we would need to remove all references to all broken packages
from mingw-dist, and probably provide a script which would repair broken
installations, so users can easily roll back to a sane state, when they
are afflicted by the breakages.

> Other package managers have the concept of an epoch, that allows
> downgrades (in the absence of an explicit epoch, zero is implied):
> 
> 4.8.1-4 (epoch = 0) < 1:4.7.2-1 (epoch = 1)
> 
> Does mingw-get already supports epochs?

No.  It's not a concept I've ever associated with package management --
I'm not aware of any such feature within apt-get, for example -- but I
can see how it could make 4.7.2 appear to be "newer" than 4.8.1.

How easily such a concept could be accommodated within mingw-get, I
don't know.  Maybe our existing subsystem version concept could provide
the requisite feature?  It would require modification, to ensure that
mingw-get ranks chronology on the basis of subsystem version before
package version, but that's likely to be more readily achievable that
introduction of a completely new concept.

> Another useful construct is "conflicts", which allows for packaging
> renaming (installing one forces removal of the other, like with versions
> upgrades, but allowing for differing base names).

Yes.  I've already slated this for inclusion in a future mingw-get, but
it isn't there yet and there are more critical issues to be resolved --
e.g. https://sourceforge.net/p/mingw/bugs/2063/ -- so I can't say when I
may get around to such enhancements.

Reorganization of package structure, between releases, perhaps isn't
impossible, but it may require a significant effort; it is not a task to
be undertaken lightly.  In addition to engineering the new package
specifications, within the catalogue, it will surely also necessitate
retro-engineering of the specifications for all prior releases -- to
ensure that the roll-back path is maintained.  That's a step which was
not adequately considered for the latest releases.

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk