| 1 |
Jean-Marc Hengen wrote: |
| 2 |
> tree and my policies (more precisely: I can't keep current stable |
| 3 |
> portage and cmake-2.6.2). My solution to the problem, was to copy the |
| 4 |
> ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. |
| 5 |
> The drawback of this workaround is, I could miss important fixes, like |
| 6 |
> security fixes. |
| 7 |
|
| 8 |
[snip] |
| 9 |
|
| 10 |
> the cmake-2.6.2 ebuild. This has the advantage, that people with a setup |
| 11 |
> like mine can continue to use, what they already use and work on the |
| 12 |
> cmake ebuild can continue in the new revision. If the new revision fixes |
| 13 |
> a security issue, one can mask the old version, with a message with bug |
| 14 |
> telling this. |
| 15 |
|
| 16 |
Just FYI, there's no difference -- when you've chosen to use the ~arch |
| 17 |
version, you *have* to follow any updates to it as soon as possible if |
| 18 |
you want to be reasonably sure you aren't affected by a security bug, as |
| 19 |
our security team doesn't issue GLSAs for ~arch packages. Sticking with |
| 20 |
a version that works for you doesn't mean you're somehow protected form |
| 21 |
security bugs. |
| 22 |
|
| 23 |
So to put this into perspective with cmake -- if there was a security |
| 24 |
bug in current version (which you'd keep as you don't want to upgrade |
| 25 |
Portage) and the fix for this bug would be using EAPI=2 (which is not an |
| 26 |
unrealistic situation), you'd be affected. |
| 27 |
|
| 28 |
Cheers, |
| 29 |
-jkt |
| 30 |
|
| 31 |
-- |
| 32 |
cd /local/pub && more beer > /dev/mouth |
Archives