[packman] [PM] realcrypt 6.3a-2.pm.3.1 (openSUSE 11.1/i586)

Axel Köllhofer AxelKoellhofer at web.de
Sun Feb 21 16:04:43 CET 2010


Da ich gerade erst bemerkt habe, daß ich bei meinen Antworten das cc an die Packman-ML verschlafen habe, hier nachträglich das Ganze, damit Lesern der Mailingliste der Zusammenhang nicht verloren geht.

Sorry für das Durcheinander.

Axel K.

Am Sunday 21 February 2010 13:14:20 schrieben Sie:
> Lieber Alex

Hallo,

> 
> Realcrypt ist kein Upgrade für Truecrypt !
> 

Siehe SPEC:

# obsolete all older versions of truecrypt
Obsoletes:      truecrypt <  %{version}-%{release}
Provides:       truecrypt == %{version}-%{release}

RealCrypt überschreibt truecrypt dann, wenn es wirklich ein Upgrade wäre, also die installierte Version von truecrypt älter ist.


> Nicht ohne Grund mußten die Fusion Leute ihrer gepachten Version 
> einen anderen Namen geben, und das Aussehen ändern.

Die einzigen Änderungen sind das andere Aussehen und der Name (aus lizenzrechtlichen Gründen), an der Funktionsweise des Programms selbst wurde nichts geändert.

Zur Erklärung:

http://en.opensuse.org/Application_Black_List

http://lists.opensuse.org/opensuse-buildservice/2008-10/msg00055.html

und

http://lists.freedesktop.org/archives/distributions/2008-October/000273.html

> 
> Es kann daher nicht sein, daß bei einem zypper dup unangefordert
> realcrypt als upgrade für truecrypt daherkommt, und truecrypt löscht 
> um sich selbst zu installieren.

Das lässt sich ganz einfach -unabhängig von jeglicher Versionierung- verhindern.

# zypper al realcrypt

oder über YaST realcrypt auf "Tabu" setzen.

Grüße,

Axel K.

Am Sunday 21 February 2010 14:49:34 schrieben Sie:
 
> Das kann so nicht stimmen. Ich hab die truecrypt version 6.3a 
> installiert, und trotzdem will sich realcrypt drüber bügeln.
 
 
Vermutlich liegt es an der "release"-Nummer des truecrypt Pakets, das kann ich zwar dann in den Obsoletes herausnehmen und nur eine "truecrypt < %{version}" setzen, aber spätestens beim nächsten Update auf eine neue Version (6.3b oder 6.4 oder wie auch immer die heissen wird), ist wieder der User gefragt,  daß er schneller von Hand updated als es ein neues RealCrypt Paket von Packman gibt (da stehen die Chancen allerdings ganz gut, denn das ist ein ziemliches Gefummel alles zu finden).
 
> Davon abgesehen wäre es auch dann inakzeptabel wenn ich eine ältere 
> Version von truecrypt nutzen würde. Realcrypt wurde von 
> irgendjemanden den ich nicht kenne, und deshalb auch nicht trauen 
> muß, modifiziert. Und weil das so ist verlangt die Lizenz zur 
> Nutzung des truecrypt Codes bei Veränderung einen Nameswechsel, um 
> deutlich zu machen das es sich hierbei nicht mehr um truecrypt 
> handelt.
> 
 
Wenn es darum geht, dann hilft nur über YaST/zypper das entsprechende Paket sperren, alles andere ist inkonsequent, wie das geht, habe ich ja schon geschrieben.
 
Komischerweise haben andere (= praktisch alle anderen open Source Projekte) Anbieter ja auch kein Problem damit, wenn man ihren Code paketiert und ggf. verändert, damit er sich ordentlich ins System einfügt und bequem über den Paketmanager installiert werden kann (statt ihn händisch über die Homepage des Anbieters updaten zu müssen).
 
Im Gegensatz zu den Paketen von truecrypt.org (zumindest habe ich nichts gefunden) ist es bei den RealCrypt Paketen sogar möglich zu sehen, was "geändert" wurde, denn bei Packman gibt es die src.rpms.

Im Endeffekt vertraut man also bei den Paketen von truecrypt.org dem Paketierer blind, bei RealCrypt muss man dies nicht tun.
 
 > Was auch immer im spec dazu frührt, das sich realcrypt als upgrade 
 > für truecrypt verhält, muß so geändert werden, das sich realcrypt 
 > nicht automatisch als truecrypt upgrade verhält. 
 > 
 
 Ich sehe keinen Grund, wieso ich das ändern "muss", niemand muss es schliesslich installieren und kann es mit einem einzigen Befehl blockieren.
 
Ein "zypper dup" ist auch alles anderes als eine "unaufgeforderte" Änderung, außerdem zeigt zypper ganz deutlich an, daß er truecrypt ersetzen will.
 
Dies ist auch ganz normale Praxis bei Namensänderungen, sogar unabhängig davon, ob nun die Funktionalität die selbe ist, siehe z.B. die ganzen Umbenennungen, beim schrittweisen Übergang von KDE3 zu KDE4.
 
Grüße,

Axel K.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.links2linux.de/pipermail/packman/attachments/20100221/c344185c/attachment.sig>


More information about the Packman mailing list