On Fri, 24 Jan 2014 10:46:06 +0000 "Steven J. Long" <[email protected]> wrote:
> Tom Wijsman wrote: > > "Steven J. Long" wrote: > > > What? Without a stable tree, Gentoo is useless afaic. > > > > It moves us closer to upstream releases, a little more bleeding > > edge; a lot of users and developers run that already, it is found > > to be useful. > > What? More vague. As are many of your philosophical statements in > later and prior mails, so I'll ignore those. It is reality; and thus, without a stable tree, Gentoo is still useful for a lot of users and developers. What is vague about that? > > > I don't think that's what was being proposed, though. The > > > question was really the old complaint about slow architectures; > > > the "-* arch" solution sounds like the most reasonable definition > > > of "dropping" keywords, in the absence of AT communication > > > otherwise. > > > > Dropping keywords and specifying -* are a world apart of each other. > > That's why it's in quotes. Why is there at all if you intend it to be irrelevant to this thread? > > The former means that it is not ready for wide stable or testing > > users, the latter means that it has been tested to not work at all; > > furthermore, we need to explicitly specify which arches in that > > case. > > You're missing the point, again. The question was what does "dropping > keywords" mean, when the maintainer has stabilised a newer version on > the arch/s s/he has available, but feels that slower archs are holding > up that process. Where is that question? > I'm slightly at a loss as to why it's such a big deal to just leave > the old ebuild as-is, given that anyone on a stabled arch should > upgrade automatically. It is when you are running the arch that only has the old version. > But given that the maintainer feels they don't want that old ebuild > around, and that the arch in question has not got round to testing the > new one, for whatever reason (it's their call, after all, as to how > their arch progresses), instead of simply removing that ebuild, or > bumping it to unstable (which makes zero sense), just leave it stable > on the slow arch/s in question, and remove the others. There are situations (security, stability, incompatibility) where keeping it in place becomes a much harder task; at which point, removal is bound to happen. At that point, such action is required. It becomes faster than you think; if you depend on a library, and the compatible range of that library gets wiped by a security bug, your package will suddenly depend on an incompatible newer stabilized version of the library at which point you are up for either a lot of hard work or plain out starting the progress of masking and removing it. > This seems like a rarity, but when it's an issue, people get annoyed > on either side. The solution proposed by the ARM team, Where is this solution? > seems like a simple way round, and indicates clearly to anyone > perusing the ebuild, that a newer version needs stabling on the > "slow" archs. Masking works fine for that too; what this does is make clear to the user that (1) the current stable version has breakage for a specific reason, (2) a newer stable version is not yet available and (3) that the user can choose to keep the breakage or upgrade to an unstable version. > By all means, raise technical objections; just not a philosophical > one. Where are these philosophical objections? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
