# --newuse nicht perfekt

## Finswimmer

Hi!

Ich habe heute nen update vom System gemacht und da kam dann, dass lirc neu installiert werden soll, da eine neue USE Flag hinzukam, die aber nicht aktiviert war.

Trotzdem wollte er es neu installieren. Am gesamten Code dürfte sich theoretisch ja nichts geändert haben.

Daher wäre ich für ein neues Zeichen im Portage (neben N,U,S,UD etc.) : C für Changes.

Dies signalisiert mir, dass eine neue Use Flag hinzukam, sie aber nicht aktiviert ist, ergo muss das Paket nicht neuinstalliert werden.

Was haltet ihr davon?

Tobi

----------

## manuels

Seltsam. Biste sicher, dass es kein (Minor-)Update ist?

Poste doch mal genau die Ausgabe von emerge.

----------

## Finswimmer

Geht leider nicht mehr, ich habe schon auf merge gedrückt.

Aber hier siehst du die letzten drei Installationen, die letzte ist von heute.

```
     Mon Jan  8 06:40:39 2007 >>> app-misc/lirc-0.8.1

       merge time: 1 minute and 55 seconds.

     Fri Feb  2 14:05:12 2007 >>> app-misc/lirc-0.8.1

       merge time: 2 minutes and 54 seconds.

     Fri Mar 16 10:04:16 2007 >>> app-misc/lirc-0.8.1

       merge time: 2 minutes and 26 seconds.
```

```
[ebuild   R   ] app-misc/lirc-0.8.1  USE="X debug -doc -hardware-carrier -transmitter" LIRC_DEVICES="atiusb -act200l -act220l -adaptec -all -alsa_usb -animax -atilibusb -audio -audio_alsa -avermedia -avermedia98 -avermedia_vdomate -bestbuy -bestbuy2 -breakoutbox -bte -bw6130 -caraca -chronos -cmdir -com1 -com2 -com3 -com4 -cph06x -creative -creative_infracd -devinput -digimatrix -dsp -dvico -ea65 -exaudio -flyvideo -gvbctv5pci -hauppauge -hauppauge_dvb -hercules_smarttv_stereo -igorplugusb -imon -imon_pad -imon_pad2keys -imon_rsc -inputlirc -irdeo -irdeo_remote -irman -irreal -it87 -knc_one -kworld -leadtek_0007 -leadtek_0010 -leadtek_pvr2000 -livedrive_midi -livedrive_seq -logitech -lpt1 -lpt2 -mceusb -mceusb2 -mediafocusI -mouseremote -mouseremote_ps2 -mp3anywhere -nslu2 -packard_bell -parallel -pcmak -pcmak_usb -pctv -pixelview_bt878 -pixelview_pak -pixelview_pro -provideo -realmagic -remote_wonder_plus -remotemaster -sa1100 -sasem -serial -serial_igor_cesko -silitek -sir -slinke -streamzap -tekram -tekram_bt829 -tira -tvbox -udp -uirt2 -uirt2_raw -usb_uirt_raw -usbirboy -userspace -xboxusb" 0 kB

```

Es ging um die uirt2_raw Flag.

Im Changelog:

 *Quote:*   

>   15 Mar 2007; Matthias Schwarzott <zzam@gentoo.org> lirc-0.8.1.ebuild:
> 
>   Added lirc device usb_uirt_raw, as requested by Robert Parenton
> 
>   <rparenton@lada.org>, Bug #170698.

 

Wie gesagt, die interessiert mich nicht die Bohne, da darf er doch nicht re-emergen wollen.

Tobi

----------

## Klaus Meier

Ja, Finswimmer ist sich sicher. Es ist so, wie er sagt. Und es nervt mich genauso wie ihn.

----------

## manuels

Hmm, da scheint portage echt nicht intelligent genug zu sein.

Das sieht nur, dass das ebuild geaendert wurde und  reemerged es (da es vielleicht ein Bug sein koennte, das behoben wurde.

Das dies dich nicht betrifft, schein wohl nicht abgefangen zu werden.

Nervig ist es, aber jetzt auch kein Weltuntergang.   :Wink: 

----------

## slick

Ich meine die Diskussion gabs in der Form schonmal bei kdehiddenvisibility was aus viele Paketen rausgeflogen ist und obwohl am Paket selbst nichts geändert wurde hat Portage es neu bauen wollen.

----------

## manuels

Ok, dann ist ein ein Weltuntergang   :Very Happy: 

Die zig Pakete neu zu kompilieren ist nervig.

----------

## Klaus Meier

 *slick wrote:*   

> Ich meine die Diskussion gabs in der Form schonmal bei kdehiddenvisibility was aus viele Paketen rausgeflogen ist und obwohl am Paket selbst nichts geändert wurde hat Portage es neu bauen wollen.

 

Wär doch mal ein Grund, da was zu ändern. Also wenn ein Flag, welches nichts bewirkt, rausfliegt, dann kann man damit doch bis zum nächsten Update warten. Und wenn ein Flag hinzukommt, dann kann dafür doch portage angepaßt werden.

----------

## manuels

Im Prinzip schon. Nur weiss Portage natuerlich nicht, ob das Flag ein neues Feature hinzufuegt (dann waere es nicht wuenschenswert neu zu kompilieren, wenn das Flag sowieso nicht gesetzt ist) oder ob das neue Flag ein Feature optional macht (dann waere es evtl. wuenschenswert neu zu kompilieren, da man danach das Feature nicht mehr drin hat, das man sowieso nicht benoetigt)

----------

## Finswimmer

 *manuels wrote:*   

> Im Prinzip schon. Nur weiss Portage natuerlich nicht, ob das Flag ein neues Feature hinzufuegt (dann waere es nicht wuenschenswert neu zu kompilieren, wenn das Flag sowieso nicht gesetzt ist) oder ob das neue Flag ein Feature optional macht (dann waere es evtl. wuenschenswert neu zu kompilieren, da man danach das Feature nicht mehr drin hat, das man sowieso nicht benoetigt)

 

Wie?

Wenn eine neue Flag hinzukommt, ich sie aber sofort deaktiviere, ist das Programm vorher und nachher identisch.

Alles andere würde das System auf den Kopf stellen.

Deswegen bin ich auch nur für eine Anzeige, dass sich was geändert hat, es aber nicht neuinstalliert wird.

Dürfte an sich nicht schwer sein das zu implementieren, denn es muss nur die neue Use Flag auf aktiv oder inaktiv überprüft werden (was sowieso schon geschieht) und wenn inaktiv statt "re-emerge" ein "changed" angezeigt/ausgeführt werden.

Und "Changed" ist: einmalige Anzeige und fertig.

Wobei ich grad merke, dass man das Portage auch erklären muss, dass es nur einmalig angezeigt werden soll.

tobi

----------

## manuels

 *Finswimmer wrote:*   

> 
> 
> Wenn eine neue Flag hinzukommt, ich sie aber sofort deaktiviere, ist das Programm vorher und nachher identisch.
> 
> Alles andere würde das System auf den Kopf stellen.
> ...

 

nee, beispiel:

Wenn du ein Feature optional machst, das vorher fest einkompiliert wurde (also das USE-Flag nicht vorhanden war), sollte es doch rausfliegen falls das neue USE-Flag nicht gesetzt ist.

Evtl. reden wir aber auch beide aneinander vorbei... 

 *Quote:*   

> 
> 
> Wobei ich grad merke, dass man das Portage auch erklären muss, dass es nur einmalig angezeigt werden soll.
> 
> 

 

----------

## Finswimmer

 *manuels wrote:*   

>  *Finswimmer wrote:*   
> 
> Wenn eine neue Flag hinzukommt, ich sie aber sofort deaktiviere, ist das Programm vorher und nachher identisch.
> 
> Alles andere würde das System auf den Kopf stellen.
> ...

 

Ok. Das löst man doch einfach dadurch, dass die Änderung angezeigt wird.

Dann habe ich als User zwei Möglichkeiten:

1) Abbrechen, Use Flag hinzufügen --> Neukompilieren

2) So lassen --> Nicht neukompilieren

Tobi

----------

## UncleOwen

 *Finswimmer wrote:*   

>  *manuels wrote:*    *Finswimmer wrote:*   
> 
> Wenn eine neue Flag hinzukommt, ich sie aber sofort deaktiviere, ist das Programm vorher und nachher identisch.
> 
> Alles andere würde das System auf den Kopf stellen.
> ...

 

Wird sie doch. -a existiert.

----------

## Klaus Meier

 *UncleOwen wrote:*   

>  *Finswimmer wrote:*    *manuels wrote:*    *Finswimmer wrote:*   
> 
> Wenn eine neue Flag hinzukommt, ich sie aber sofort deaktiviere, ist das Programm vorher und nachher identisch.
> 
> Alles andere würde das System auf den Kopf stellen.
> ...

 

Aber das löst das Problem nicht, weil es ja jedes Mal angezeigt wird. Und man hat es dann bei jedem Update. Und "-a" erlaubt nur ganz oder gar nicht. Entweder ich breche alles ab oder ich übersetze alles.

----------

## slick

Ok, gehen wir doch mal systematisch an die Sache heran. Nehmen wir als Beispiel folgendes Szenario:

Das Paket "irgendwas-artwork-1.0" hat kein Useflag. Jetzt kommt über Nacht eine neue Version 2.0 mit dem neuen Useflag "extrabunt" hinzu, welche die Bilder noch zusätzlich irgendwie behandelt.

Ohne das das Useflag "extrabunt" gesetzt ist handelt es sich also um exakt das gleiche Ergebnis. portage hat aber davon keinen Plan. Es "sieht" nur das im Ebuild plötzlich in IUSE was neues steht. 

Um dann den gewünschten Effekt zu erzielen müßte die IUSE-Variable so umgebaut werden das jedes Useflag eine Art "Change-Wert" erhält. Das müßte dann schematisch ungefähr so aussehen:

```
IUSE="extrabund (new_additional)"
```

Das würde aussagen das dieses Useflag eine zusätzliche Funktionalität bereitstellt und ist dieses nicht gesetzt der Vorgängerversion entspricht und darum nicht neu kompiliert werden muss. 

Das allein würde schon einem kompletten Umbau von Portage inkl. aller (betroffenen) Ebuild bedeuten.

Dann bleibt aber immernoch folgende Frage: Welche ist die "Vorgängerversion"? In dem Fall wäre es "irgendwas-artwork-1.0", doch was ist wenn der Nutzer die "inkompatible" Version "irgendwas-artwork-0.5" installiert hat? Was passiert dann? 

Also schlußfolgernd daraus müßte die Versionsnummer noch in die IUSE Beschreibung mit aufgenommen werden. Schematisch etwas so:

```
IUSE="extrabund (new_additional_to_1.0)

extrabund (complete_new_to_0.5)"
```

Das würde bedeuten ein Übersetzen des Paketes wäre nur beim Updaste von Verison 0.5, nicht aber 1.0 nötig. Was ist aber mit den ganzen anderen Versionen? Jemand hat vielleicht noch 0.4 installiert? Daraus folgt, es müßten in jedem Ebuild alle vorhergegangenen Versionen beachtet werden.

Und bevor ich den Devs zumute sowas zu coden und anschliessend zu verwalten bau ich lieber ein Paket neu, auch wenn es eigentlich nicht nötig wäre...

----------

## Finswimmer

Ist das nicht zu schwarz gesehen?

Auf die Gefahr hin, dass ich mich wiederhole.

Es kommt eine neue Flag bei gleichbleibender Version hinzu:

Portage erkennt dies, zeigt sie mit einem Flag% an.

Je nachdem, was make.conf package.keywords sagt: +Flag% oder -Flag%

Soweit ist alles schon implementiert.

Nun noch die neue Funktion rein: Wenn -Flag%, dann nur einmalige Anzeige.

Ich sehe damit alle Fälle abgehandelt.

Tobi

----------

## slick

 *Finswimmer wrote:*   

> Es kommt eine neue Flag bei gleichbleibender Version hinzu:

 

Wäre die Version _gleich_, warum dann das Useflag? Du gehts außerdem davon aus das ein Useflag immer eine neue zusätzliche Funktionalität beinhaltet, was aber wenn etwas "wegfällt" wenn Du das Useflag nicht gesetzt hast?

----------

## pablo_supertux

 *Finswimmer wrote:*   

> 
> 
> Wenn eine neue Flag hinzukommt, ich sie aber sofort deaktiviere, ist das Programm vorher und nachher identisch.
> 
> Alles andere würde das System auf den Kopf stellen.

 

nein, nicht zwangsläufig. Darüber habe ich mir Gedanken gemacht, denn mich nervt es auch, dass manche Pakete (wie php) sehrt oft per --new-use kompiliert werden, nur weil eine USE Flag neu kommt, die deaktiviert ist. 

Aber wenn du ein Feature hast, das nicht per USE ansteurbar ist aber default vom configure aktiv ist und dann später eine neue USE Flag kommt, das dieses Feature (default) deaktiviert, dann sollte das Paket neu gebaut werden, denn unter Umständen könnte dieses Feature dein System zerschießen (wenn andere Pakete erwarten, dass diese Flag deaktiviert ist). Hatten wir nicht mal ein ähnliches Problem damals mit nptl, nptl-only und linux-threads bei der Glibc? Ich kann mich erinnern, dass ich mal deswegen mein system zerschossen habe, weil ich irgendwas nicht deaktiviert habe. Ich weiß es nicht mehr, es ist lange her.   :Cool: 

----------

## Finswimmer

 *pablo_supertux wrote:*   

> 
> 
> Aber wenn du ein Feature hast, das nicht per USE ansteurbar ist aber default vom configure aktiv ist und dann später eine neue USE Flag kommt, das dieses Feature (default) deaktiviert, dann sollte das Paket neu gebaut werden, denn unter Umständen könnte dieses Feature dein System zerschießen (wenn andere Pakete erwarten, dass diese Flag deaktiviert ist).

 

Ok. Seh ich ein.

Dann machen wir es doch so: 

Portage zeigt eine neue Use Flag mit -/+ Flag% an. Vorne das Zeichen C. Und dann wird halt eine Abfrage reingesetzt: merge? ja/nein

Tobi

----------

## pablo_supertux

 *Finswimmer wrote:*   

> 
> 
> Portage zeigt eine neue Use Flag mit -/+ Flag% an. Vorne das Zeichen C. Und dann wird halt eine Abfrage reingesetzt: merge? ja/nein
> 
> 

 

es wäre so schön, wenn das so einfach ginge. Aber ich denke, dass man USE Flags nicht zum Spaß hinzufügt, sondern weil man am Paket etwas wirklich geändert hat, ob an den features oder am Build Prozess. Außerdem sehen ich den Einsatz von diesem C Buchstaben nicht als praktikabel, denn man müssen sozusagen Buch führen, ob man ein update oder kein macht. Woher soll portage wissen, dass das Paket sich nicht ändert? Du müsstest eine Variable im ebuild dafür haben. Ich kann mir irgendwie schwer vorstellen, wie man das am besten lösen könnte.

Am besten tust du deinen Vorschlag in die dev- Mailing List.

----------

## sirro

 *Finswimmer wrote:*   

> Abfrage

 

Das setzt allerdings voraus, dass du weisst was das ebuild vorher gemacht hat und was das Flag daran ändert. Wenn du das nicht weißt sind wir wieder beim System zerschiessen weil ein anderes ebuild abfragt "hat der damit gebaut? ne?! gut, dann kann ich ja nix kaputt machen und starte".

Früher konnte man sowas mal direkt in der DB ändern. Aber den Tipp will ich keinem geben, auch wenn ich wissen würde, dass es noch geht. Aber sein System auf ne andere Weise zerschiessen will, der kann es ja mal probieren...

----------

## Finswimmer

 *Quote:*   

> Aber ich denke, dass man USE Flags nicht zum Spaß hinzufügt, sondern weil man am Paket etwas wirklich geändert hat, ob an den features oder am Build Prozess

 

 *Quote:*   

> Das setzt allerdings voraus, dass du weisst was das ebuild vorher gemacht hat und was das Flag daran ändert. 

 

Ich ärgere mich eher über so kleine UseFlags wie die angesprochene usb_uirt_raw Flag bei lirc.

Die interessiert mich nicht.

 *Quote:*   

> Wenn du das nicht weißt sind wir wieder beim System zerschiessen weil ein anderes ebuild abfragt "hat der damit gebaut? ne?! gut, dann kann ich ja nix kaputt machen und starte". 

 

Wenn ich die --newuse Option weglasse, kann es mir auch passieren, oder?

Ich sehe das als zusätzliches Feature, nicht als allesheilende Lösung.

Wenn ich (also ich persönlich) nicht weiß, was die Use Flag macht, dann würde ich, mit dem Hintergrundwissen von diesem Thread, auf Nummer sicher gehen, und es durchlaufen lassen.

ABER: Bei 90% der Flags kann man sehen, dass sie mir nicht schaden, und um die geht es mir, dass ich da das neue Kompilieren verhindern kann.

Tobi

----------

## sirro

 *Finswimmer wrote:*   

>  *Quote:*   Wenn du das nicht weißt sind wir wieder beim System zerschiessen weil ein anderes ebuild abfragt "hat der damit gebaut? ne?! gut, dann kann ich ja nix kaputt machen und starte".  
> 
> Wenn ich die --newuse Option weglasse, kann es mir auch passieren, oder?

 

Erwischt  :Embarassed: 

Ich weiss es nicht genau, aber ich denke mal, dass es auf's gleiche rausläuft.

----------

## pablo_supertux

 *Finswimmer wrote:*   

> 
> 
> Ich ärgere mich eher über so kleine UseFlags wie die angesprochene usb_uirt_raw Flag bei lirc. 
> 
> Die interessiert mich nicht.
> ...

 

keine Frage, ich ärgere mich auch deswegen, vor allem bei php. Manchmal installiert man php 3 Mal hintereinander, nur weil am nächsten Tag eine neue USE Flag kommt. Das ist nun mal so, wenn man emerge -uvaDN world täglich ausführt.

 *Finswimmer wrote:*   

> 
> 
> Wenn ich die --newuse Option weglasse, kann es mir auch passieren, oder?
> 
> 

 

ich würde sagen nein, denn das Ebuild ind /var/db/pkg/*/*/*.ebuild die alte Information enthät und dann wird das Ebuild mit dieser Abhängigkeit dich drauf hinweisen, dass du Paket-xyz mit der USE Flag -irgendwas installieren sollst.

----------

## Genone

Um das ganze mal etwas zusammenzufassen:

1) --newuse macht genau das was es soll, nämlich Pakete anzuzeigen wo sich der Zustand der USE Flags geändert hat

2) Wenn ein USE Flag neu hinzukommt oder entfernt wurde ist das eine Änderung egal ob es aktiviert ist oder nicht, da der vorherige Zustand undefiniert ist. Man könnte das theoretisch mit zusätzlichen Metadaten wohl hinbiegen, das Kosten-Nutzen Verhältnis ist aber relativ schlecht da wieder diverse Sonderfälle auftauchen würden und es allgemein mehr Verwaltungsarbeit wäre.

3) Das Hauptproblem denke ich ist dass Leute --newuse mit der nicht existenten --list-all-packages-I-must-rebuild-asap Option verwechseln. Was man mit der Ausgabe von --newuse anfängt muss man schon selber entscheiden.

4) Evtl. wird es in einer zukünftigen Version von Portage die Möglichkeit geben das Verhalten von --newuse genauer zu steuern und/oder bestimmte Updates/Rebuilds temporär zu blocken. Aber wie gesagt, nur eventuell.

----------

## ChrisJumper

*hust* Ich bin ja noch nicht so Fit wie ihr.

Aber bisher dachte ich immer. Das man neue Useflags setzen kann. Diese aber dann einfach "Hellgrün" aufleuchten, mit einem Sternchen dran. Diese werden dann beim nächsten emerge dieses Paketes übernommen oder wenn ich das Flag --newuse (-N) benutze.

Von daher verstehe ich den Sinn dieser Diskussion nicht.

Denn normalerweise ist es doch so das selbst wenn eine "Neues" Useflag kreiert wird oder ein neues Useflag zu einem Paket hinzugefügt wird der Fall das es:

entweder eine Weiterentwicklung ist, und man hatte vorher nicht das Bedürfnis dieses Useflag zu verwenden.

Oder man hat es sowieso schon gesetzt weil es ja irgendwo auch im System benutzt wird.

Von daher wäre es auch nicht schlimm wenn man eine "Standard"-Funktion beim nächsten mal hinauswirft und extra Useflags dafür definiert. Denn wer es benutzt hat es gesetzt. Oder es wird Systemweit entfernt und dann hat man es auch nicht wirklich nötig?

Aber davon ganz abgesehen. Vor jedem größeren emerge schaut man sich doch soweiso die Useflags mal an.

Ich bin mir sogar ziemlich Sicher das neue Useflags bei gesetztem -pv besonders hervorgehoben werden wodurch man doch noch besonders drauf Aufmerksam gemacht wird. War es nicht das %-Zeichen?

 *Quote:*   

> --verbose
> 
>               Tell emerge to run in verbose mode.  Currently this flag causes emerge to print
> 
>               out GNU info errors, if any, and to show the USE flags that will  be  used  for
> ...

 

Quelle: man emerge

----------

## pablo_supertux

 *Genone wrote:*   

> 
> 
> 1) --newuse macht genau das was es soll, nämlich Pakete anzuzeigen wo sich der Zustand der USE Flags geändert hat
> 
> 

 

das hatte ich so nicht betrachtet, aber das stimmt ja auch.

----------

## a.forlorn

Bin schon eine ganze Weile von emerge -uDN world weg, letztendlich bringt es mir nichts, für packages updates durchzuführen, die von meinen gewünschten packages (worldfile) nicht gebraucht werden. Und weil eine useflag sich geändert hat Openoffice neu zu kompilieren, macht keinen Sinn imo.  :Wink: 

----------

## Klaus Meier

 *a.forlorn wrote:*   

> Bin schon eine ganze Weile von emerge -uDN world weg, letztendlich bringt es mir nichts, für packages updates durchzuführen, die von meinen gewünschten packages (worldfile) nicht gebraucht werden. Und weil eine useflag sich geändert hat Openoffice neu zu kompilieren, macht keinen Sinn imo. 

 Ok, du bist von emerge -uDN weg, aber wo bist du hin? Die Existenz von Dingen, ist nicht davon abhängig, ob sie für dich einen Sinn ergeben. Also das System von Gentoo und den USE-Flags hast du schon verstanden?

----------

