# [gelöst]portage-2.*

## flammenflitzer

Hallo,

bin gerade über EAPI 4 gestolpert, da ich mich für libbluray interessiert habe.

```
flammenflitzer olaf # emerge libbluray

Calculating dependencies... done!

!!! All ebuilds that could satisfy "libbluray" have been masked.

!!! One of the following masked packages is required to complete your request:

- media-libs/libbluray-9999 (masked by: EAPI 4)

- media-libs/libbluray-0.0.1_pre20110210 (masked by: EAPI 4)

The current version of portage supports EAPI '3'. You must upgrade to a

newer version of portage before EAPI masked packages can be installed.

For more information, see the MASKED PACKAGES section in the emerge

man page or refer to the Gentoo Handbook
```

Dabei habe ich festgestellt. das bei Gentoo für ~amd64 nur bis portage-2.1.9.40 vefügbar ist, bei funtoo dagegen portage-2.2.2. Vor geraumer Zeit war bei gentoo allerdings auch portage-2.* für ~amd64 verfügbar. Jetzt nicht mehr. Kennt jemand die Hintergründe?Last edited by flammenflitzer on Fri Feb 18, 2011 7:05 pm; edited 1 time in total

----------

## Necoro

Portage-2.2 ist Portage-2.1.9 plus das 'preserved-libs' Dingens. Da letzteres wohl nicht komplett zufriedenstellend arbeitet, ist es wohl gemasked.

Aber mein portage (2.1.9.36) unterstützt bereits EAPI=4 -- insofern gibt es keinen Grund auf 2.2 upzugraden.

----------

## schachti

portage 2.2.x gibt's auch für AMD64, allerdings ist es hard masked:

```
# emerge -pv portage

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   *] sys-apps/portage-2.2.0_alpha24  USE="(ipc) -build -doc -epydoc -python2 -python3 (-selinux)" LINGUAS="-pl" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

```

EDIT: Korrektur: Es ist nicht hard masked, es fehlen nur die Keywords:

 *http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/ChangeLog?view=markup wrote:*   

> 
> 
> 01 Nov 2010; Zac Medico <zmedico@gentoo.org> portage-2.2_rc67.ebuild,
> 
>  	portage-2.2.0_alpha1.ebuild, portage-2.2.0_alpha2.ebuild,
> ...

 

Also einfach

```

<sys-apps/portage-9999 **

```

in /etc/portage/package.keywords eintragen.

----------

## flammenflitzer

Danke

----------

## Josef.95

 *Quote:*   

> [...]Also einfach
> 
> ```
> <sys-apps/portage-9999 **
> ```
> ...

 

Da man solche Einträge meist wieder vergisst, und nicht bekannt ist wie sich Portage weiterentwickelt würde ich zunächst "nur" etwas wie 

```
=sys-apps/portage-2.2* ~*
```

 setzen, das sollte aktuell ausreichen.

/edit:

Und falls du "preserve-libs" wirklich nicht nutzen möchtest dann könntest du es auch in der make.conf unter FEATURES deaktivieren.

----------

## Necoro

 *Josef.95 wrote:*   

> /edit:
> 
> Und falls du "preserve-libs" wirklich nicht nutzen möchtest dann könntest du es auch in der make.conf unter FEATURES deaktivieren.

 

Nur stellt sich denn die Frage, welchen Vorteil die Benutzung von Portage-2.2 hat... bzw denn kann man das mit der Demaskierung auch lassen.

----------

## Josef.95

 *Necoro wrote:*   

>  *Josef.95 wrote:*   /edit:
> 
> Und falls du "preserve-libs" wirklich nicht nutzen möchtest dann könntest du es auch in der make.conf unter FEATURES deaktivieren. 
> 
> Nur stellt sich denn die Frage, welchen Vorteil die Benutzung von Portage-2.2 hat... bzw denn kann man das mit der Demaskierung auch lassen.

 

Nunja, ob das Problem wegen dem in der testing (2.1) Version anscheinend nicht unterstützte "EAPI 4" nun durch ein Upgrade auf portage-2.2 gelöst werden könnte, das kann ich nicht beurteilen... (ich nutze seit Jahren ausschließlich portage-2.2)

Doch grade auch der Umgang mit Overlays ist mit portage-2.2 wesentlich besser und einfacher zu handhaben da zb nun auch Repositories verwaltet und konfiguriert werden können. (siehe dazu zb auch hier)

----------

## mv

 *Necoro wrote:*   

> Nur stellt sich denn die Frage, welchen Vorteil die Benutzung von Portage-2.2 hat...

 

Ich benutze seit gefühlten Jahren portage-2.2 mit abgeschaltetem preserve libs. Wichtige Vorteile: Es gibt sets. Sehr nützlich. Beispielsweise 

```
emerge @module-rebuild
```

 oder  

```
emerge @x11-module-rebuild
```

 oder bei mir (mit einer selbstgeschriebenen Paket-Liste für firefox-extensions):

```
emerge @firefox-extensions
```

 Manche Overlays (kde) enthalten sogar eigene sets.

Es gehen Einträge wie kde-base/* in package.accept_keywords

Es gehen auch Overlay-Namen wie */*::mein_locales_repository in package.accept_keywords

Man kann die Reihenfolge von Overlays angeben.

Möglicherweise sind einige der Features inzwischen nach portage-2.1 zurückportiert, aber ich sehe eigentlich keinen Grund, portage-2.2 nicht zu benutzen (wenn man preserve libs abschaltet).

----------

## schachti

 *mv wrote:*   

> Ich benutze seit gefühlten Jahren portage-2.2 mit abgeschaltetem preserve libs.

 

Warum hast Du dieses Feature deaktiviert? Es scheint bei mir ganz gut zu funktionieren...

 *mv wrote:*   

> 
> 
> Man kann die Reihenfolge von Overlays angeben.
> 
> 

 

Hättest Du dafür ein Beispiel?

----------

## mv

 *schachti wrote:*   

>  *mv wrote:*   Ich benutze seit gefühlten Jahren portage-2.2 mit abgeschaltetem preserve libs. 
> 
> Warum hast Du dieses Feature deaktiviert? Es scheint bei mir ganz gut zu funktionieren...

 

Mir ist es lieber, dass etwas nicht startet, als dass ich eine alte Library mit Sicherheitslöchern benutze: Da preserved libs die alte Library behält, weiß man - falls die neue Library Sicherheitslöcher schließt - nicht, dass man die Anwendung neu kompilieren sollte. Klar, wenn man nach jedem emerge ein emerge @preserved-rebuild aufruft schon, aber wenn man es mal vergisst (oder portage aus bestimmten Gründen bei der Library versagt), hat man u.U. ein unsicheres System und merkt es nicht.

Übrigens nicht nur Sicherheitsgründe, sondern auch Stabilität des System: Es ist einfach besser, wenn man eine nicht mehr benötigte Library sofort entfernt, so dass nichts diese versehentlich benutzt (denn auch im Build-System von Paketen oder Ebuilds kann es Bugs geben).

 *Quote:*   

>  *mv wrote:*   
> 
> Man kann die Reihenfolge von Overlays angeben.
> 
>  
> ...

 

Es gibt eine /etc/overlay.conf oder so ähnlich - findet sich sicher in Foren oder der manpage: Das ist das einzige Feature, das ich noch nicht benötigt habe, denn für meine Zwecke war das Maskieren/Unmaskieren der einzelnen Pakete in Overlays (bzw. der gesamten Overlays mit */*::repo_name) immer ausreichend, aber ich benutze auch i.W. nur meine eigenen Overlays.

----------

## Necoro

 *Josef.95 wrote:*   

>  *Necoro wrote:*    *Josef.95 wrote:*   /edit:
> 
> Und falls du "preserve-libs" wirklich nicht nutzen möchtest dann könntest du es auch in der make.conf unter FEATURES deaktivieren. 
> 
> Nur stellt sich denn die Frage, welchen Vorteil die Benutzung von Portage-2.2 hat... bzw denn kann man das mit der Demaskierung auch lassen. 
> ...

 

Wie ich oben schon schrieb (liest eigentlich niemand die Posts?), können die Portage-2.1.*-Versionen EAPI=4

/edit: Und das mit der Reihenfolge der Overlays kann Portage-2.1 auch  :Smile:  ...

----------

