28.2.2006, 17:35:32, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer <[EMAIL PROTECTED]> > wrote: > | Ok, sorry for being dumb :-) > | What exactly is the issue there? I don't see the issue in setting SLOT > | depending on ... uhm ... some variable. Looks kinda logical at first > | glance, but I'm not aware of the issues it causes.
> PVR includes the revision of an ebuild. This means that if a revbump is > made on a webapp package to fix a critical flaw, users will still have > the old broken package installed too. This is especially relevant for > security issues, but also applies to other kinds of fix. Not including the revision into the SLOT can break the apps by removing the needed files from a live site... I still can't see any *QA* violation there. > Ebuilds can't override this either. Read on in the eclass and you'll > notice that it checks that SLOT hasn't been changed to something sane. Yeah, it checks for that since that's the way the eclass is designed. You can't declare a slot in a kernel ebuild either. Well, starts to be boring - so, either come with something valid from QA standpoint or stop now. -- jakub
pgpdnAxBRtsYS.pgp
Description: PGP signature
