| 1 |
28.2.2006, 17:35:32, Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
> On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer <patrick@g.o> |
| 4 |
> wrote: |
| 5 |
> | Ok, sorry for being dumb :-) |
| 6 |
> | What exactly is the issue there? I don't see the issue in setting SLOT |
| 7 |
> | depending on ... uhm ... some variable. Looks kinda logical at first |
| 8 |
> | glance, but I'm not aware of the issues it causes. |
| 9 |
|
| 10 |
> PVR includes the revision of an ebuild. This means that if a revbump is |
| 11 |
> made on a webapp package to fix a critical flaw, users will still have |
| 12 |
> the old broken package installed too. This is especially relevant for |
| 13 |
> security issues, but also applies to other kinds of fix. |
| 14 |
|
| 15 |
Not including the revision into the SLOT can break the apps by removing the |
| 16 |
needed files from a live site... I still can't see any *QA* violation there. |
| 17 |
|
| 18 |
> Ebuilds can't override this either. Read on in the eclass and you'll |
| 19 |
> notice that it checks that SLOT hasn't been changed to something sane. |
| 20 |
|
| 21 |
Yeah, it checks for that since that's the way the eclass is designed. You |
| 22 |
can't declare a slot in a kernel ebuild either. |
| 23 |
|
| 24 |
Well, starts to be boring - so, either come with something valid from QA |
| 25 |
standpoint or stop now. |
| 26 |
|
| 27 |
-- |
| 28 |
|
| 29 |
jakub |
Archives