El sáb, 30-06-2012 a las 13:17 -0400, Ian Stakenvicius escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 30/06/12 11:16 AM, Mike Frysinger wrote: > > On Saturday 30 June 2012 07:22:39 Zac Medico wrote: > >> On 06/30/2012 04:07 AM, Pacho Ramos wrote: > >>> I would like to discuss a bit more issues like: > >>> https://bugs.gentoo.org/show_bug.cgi?id=423087 > >>> > >>> Even if there are "a lot" of packages that can cause this > >>> breakage when downgraded, I think it should be prevented and > >>> package managers shouldn't try to downgrade this kind of > >>> packages as they will later cause a total breakage. People is > >>> not supposed to know that downgrading some package system will, > >>> for example, have an unusable gcc. > >> > >> It seems like a die in pkg_pretend would serve pretty well. > > > > doing it on a per-ebuild basis doesn't make much sense. a simple > > version compare (like we do in glibc as an exception to this rule > > because of its much wider implication) is incorrect: the new > > version might not introduce any new symbols compared to the old > > one, and even if it has, other packages might not have been linked > > against the new symbols. -mike > > Instead of preventing downgrade wouldn't it make more sense to figure > out a way to force a rebuild on @system or @toolchain or whatever bits > are broken as soon as the downgrade occurs, rather than just making it > a one-way ticket? If we could sort this out (and sub-slots may help > with this, but probably we'll need some extra work too) then we could > probably support switching from ~arch to arch at a whim.. Not > necessarily a bad goal. >
The problem is that, in this kind of breakage, gcc breaks as soon as zlib is downgraded and, then, user cannot compile anything, needing to manually find missing zlib lib from any other distributions binaries, put it in the system and re-emerge zlib :|
signature.asc
Description: This is a digitally signed message part
