Cambio di packaging per wine e mdkonline impazzisce

[GvMariani]

L'ultimissima versione di wine, prodotta da grissino, prevede solo due pacchetti (wine e wine-devel: cfr http://mib.pianetalinux.org/mib/it/prog ... -1138.html), laddove quella precedente ne prevedeva tre (wine, libwine1 e libwine-devel).

Un risultato imprevisto del cambiamento, però, è che ora mdkonline mi propone come "upgrade" l'installazione dei pacchetti libwine1 e libwine-devel della versione 1.1.37 che erano stati correttamente rimossi nell'upgrade alla nuova versione...

Che fare?

GvM

[NicCo]

Hai provato a rimuoverle?

Code: Select all

urpme libwine1 libwine-devel

magari ti sono rimasti ancora dalla precedente versione 1.1.36 e ti vuole aggiornare a 1.1.37



P.S: Il cambio di packaging è avvenuto perchè di già il wine passa il build a 64bit, anche se ancora dà qualche segfault:
quindi in seguito avremo anche wine64 e wine64-devel, per una esecuzione ottimizzata dei programmi in windows 64...

Ciao,
NicCo

[bright77]

Appena avrò un po' di tempo, cercherò di verificare.
Si potrebbe risolvere il problema aggiungendo una direttiva "Conflicts" nel file SPEC.

[GvMariani]

Hai provato a rimuoverle?
magari ti sono rimasti ancora dalla precedente versione 1.1.36 e ti vuole aggiornare a 1.1.37

Non sono installati per niente (l'aggiornamento alla 1.1.38 evidentemente li ha correttamente rimossi):

rpm -qa|grep wine
wine-gecko-1.0.0-69.1mib2010.0
wine-1.1.38-69.1mib2010.0
wine-devel-1.1.38-69.1mib2010.0
lib64kwineffects1-4.3.5-69.1mib2010.0

Ma sono l'unico con 'sta cosa?
Visto che prima tutti quelli che avevano i pacchetti di wine del MIB avevano anche gli altri rpm installati, mi aspetterei che anche altri, dopo l'ultimo upgrade, godessero della stessa "feature" ...

GvM

[bright77]

Ho provato con una nuova installazione, ad aggiornare da wine mandriva a wine mib, ma non ho notato alcun problema.

Se non si verifica ad altri, direi di non preoccuparsi.
Ciao!

[x4nder]

Stesso problema anche io.
Ho appena aggiornato dai repo MIB Wine alla versione 1.1.39. Tutto liscio.
Ora però mi viene notificata la presenza di ulteriori aggiornamenti (sempre dai repo MIB) di questi due pacchetti:
libwine-devel - 1.1.37
libwine1 - 1.1.37
Quando li installo mi da chiaramente diversi errori per conflitto di versione.
Faccio presente che non sono installati in nessuna versione.

[GvMariani]

Stesso problema anche io.
Ho appena aggiornato dai repo MIB Wine alla versione 1.1.39. Tutto liscio.
Ora però mi viene notificata la presenza di ulteriori aggiornamenti (sempre dai repo MIB) di questi due pacchetti:
libwine-devel - 1.1.37
libwine1 - 1.1.37
Quando li installo mi da chiaramente diversi errori per conflitto di versione.
Faccio presente che non sono installati in nessuna versione.

Infatti non devi per niente installarli: i pacchetti della 1.1.39, infatti, provvedono già a mettere tutto il necessario...
Il fatto è che, nel frattempo, è cambiata la pacchettizzazione (wine + wine-devel in luogo dei precedenti wine + libwine
+ libwine-devel...) e, a quanto pare, rpm / urpmi /mdkonline non se ne accorgono e continuano a proporti di installare le versioni più recenti dei pacchetti che non ci sono più.

Per ora non sono riuscito in nessun modo a aggirare il problema:
* né utilizzando la skip.list di urpmi;
* nè disinstallando del tutto wine e reinstallandolo all'ultima versione.
D'altra parte, l'unica conseguenza di questo stato di cose è l'impossibilità di usare urpmi --auto-select (altrimenti la transazione di cui fan parte i pacchetti incriminati fallisce sempre...) e quindi - per ora - non è altro che una gran rottura, priva di conseguenze operative.

Mi piacerebbe dare uno sguardo al file spec con cui sono stati fatti i pacchetti MIB: mi sa che manca qualche istruzione "obsoletes"...

GvM

[SymbianFlo]

secondo me basta compilare il wine nuovo con Obsoletes: vecchio_wine_tutto

[NicCo]

Verificate di avere installato solo il pacchetto rpm chiamato wine, e non anche wine-devel

Mi sono accorto che se rimuovete wine-devel l'errore non si verifica più, è lì il problema!

Code: Select all

urpme wine-devel

ciao,
NicCo

[x4nder]

Risolto. Grazie.

[GvMariani]

Infatti.
Il problema sta proprio lì:
manca un qualche "obsoletes" (come suggeriva SymbianFlo) nello spec di wine-devel e questo rimette in gioco il vecchio libwine-devel, il quale - a sua volta - si riporta dietro il libwine corrispondente (ed infatti, se lancio rpmdrake, sotto upgrades compare solo libwine-devel...).

Tuttavia, almeno a un primo sguardo ai file spec sia del MIB che di Cooker, non mi sembra che manchi niente:

Code: Select all

%package -n	%{wine}-devel
Summary:	Static libraries and headers for %{name}
Group:		Development/C
Requires:	%{wine} = %{epoch}:%{version}
Provides:	%{lib_name_devel} = %{epoch}:%{version}-%{release}
Provides:	%{lib_name_orig}-devel = %{epoch}:%{version}-%{release}
Obsoletes:	%{lib_name_devel} <= %{epoch}:%{version}-%{release}
Obsoletes:	%{mklibname -d wine 1} < %{epoch}:%{version}
%ifarch %{ix86}
Conflicts:	wine64-devel
%else
Conflicts:	wine-devel
%endif

laddove i vari "lib_name*" sono così definiti:

Code: Select all

%define	lib_name_orig	lib%{name}
%define	lib_major	1
%define	lib_name	%mklibname %{name} %{lib_major}
%define	lib_name_devel	%{mklibname -d wine}

Qualcuno degli esperti di spec file, sa dirmi perché non funzionano le due clausole "Obsoletes" già presenti?

GvM

[SymbianFlo]

%ifarch %{ix86}
Conflicts: wine64-devel
%else
Conflicts: wine-devel
%endif

dici che va bene ?hmmmm
conflitta solo tra le architetture e non tra le obsoletes e questa %_version
traduciamo .
se 32 bit allora conflitta con devel64 altrimenti con devel32, e poi ?
e poi .

Obsoletes: %{lib_name_devel} <= %{epoch}:%{version}-%{release}
Obsoletes: %{mklibname -d wine 1} < %{epoch}:%{version}

Funzionerebbe se il nuovo pachetto/i hanno un epoch superiore.
Definire le major con una superiore non puo "obsolire" ( se si puo dire)
una vecchia %_version, non fa altro che nei build futuri ladove viene usato come
Buildrequires o Requires viene usato in assolutto questo con la major diversa
spesso succede che nome-lib-so.%_maggior vada in conflitto con nome-lib-so.%_maggior+1
semplicemente perche la sezione obsoletes sullo spec e sbagliata.

se lo hanno fatto in cooker cosi , allora e grave .....
ma lascio la parola agli esperti