| 1 |
On Saturday 09 Jul 2016 23:22:49 I wrote: |
| 2 |
> On Sunday 10 Jul 2016 04:08:36 Michael Palimaka wrote: |
| 3 |
|
| 4 |
--->8 |
| 5 |
|
| 6 |
> > This change is correct - we're in the process of cleaning up some old |
| 7 |
> > ebuilds at the moment. |
| 8 |
> > |
| 9 |
> > In this case kde-apps/kdebase-runtime-meta:5 doesn't imply anything |
| 10 |
> > KF5-based - it has just been ported to use a newer eclass. It still just |
| 11 |
> > pulls in the old KDE4-based kde-runtime packages. |
| 12 |
|
| 13 |
I don't think that's entirely true; see below. |
| 14 |
|
| 15 |
> That's good news. Now, how does one allow that package to be installed while |
| 16 |
> keeping the rest of KF5 masked? |
| 17 |
> |
| 18 |
> # cat /etc/portage/package.mask |
| 19 |
> kde-plasma/* |
| 20 |
> kde-frameworks/*:5 |
| 21 |
> kde-apps/*:5 |
| 22 |
> kde-misc/*:5 |
| 23 |
> >=kde-apps/kde4-l10n-16.04.1 |
| 24 |
> |
| 25 |
> We seem to need an analogue of CONFIG_PROTECT and CONFIG_PROTECT_MASK, in |
| 26 |
> which we could mask all kde-apps/*:5 while allowing |
| 27 |
> kde-apps/kdebase-runtime-meta:5 to be installed. Can that be done? I hope |
| 28 |
> there's an easier way than masking all 122 apps separately. |
| 29 |
|
| 30 |
In fact I tried the separate masking. It led on to having to treat kde-plasma |
| 31 |
and kde-frameworks similarly, and before I knew it I was unmasking a load of |
| 32 |
packages that don't belong in a KDE-4 system. |
| 33 |
|
| 34 |
What to try next? |
| 35 |
|
| 36 |
-- |
| 37 |
Rgds |
| 38 |
Peter |
Archives