Verwaltung mehrerer Produktversionen mit gleicher ProduktID möglich ?

[ueluekmen]

Hi,

Bei der Anwenderumfrage 2014/2015 habe ich genau zu diesem Thema einen ziemlich langen Absatz unter "was wäre wünschenswert" hinterlassen, mit einer Beschreibung, wie das logisch gehen könnte.

ich habe das nochmal nachgelesen und jetzt auch noch mal hier. Wenn man das von der momentan Datenstruktur betrachtet ist eigentlich alles dafür schon da.

innerhalb von opsi selber würde ich eh zu einer völlig eigenen, internen Paketkennung wechseln, und nicht das verwenden, was "wir" Endanwender beim Paketbau da so alles reinhacken

Wenn wir das machen, dann wirds ganz schnell noch verwirrender. Aber ich denke das ist an der Stelle auch gar nicht nötig. Aus Sicht des Backends sind parallele Versionen durchaus möglich und das muss sogar so sein, denn in einer Multidepot-Umgebung kann ein product durchaus in verschiedenen Versionen auf den Depots vorhanden sein. Zwangsläufig wenn die Depots nach der Reihe aktualisiert werden.
Auch bei den Abhängigkeiten kann man durchaus detailiert sagen, welche Version vom Abhängigen Produkt benötigt wird. Damit ist es jetzt schon durchaus möglich über ein Metapaket oder für dich Releasepackage die Abhängigkeiten detailiert zu setzen. Das eigentliche Problem wäre hier die Restriktion dass eine productId nur einmal an einem Depot registriert werden kann. Auch hier ist nicht das Backend das Problem sondern die Businesslogik drüber. Man müsste dann sowas wie /var/lib/opsi/depot/productId-softwareversion-packagesversion machen. Das ist jetzt einfach mal naiv nachgedacht, da natürlich einige Änderungen über die ich jetzt noch nicht nachdenken möchte dafür notwenig wären.

Bevor ich das in ein internes Diskussionsticket eintüte, will ich nur sichergehen, dass ich das wirklich richtig verstehe.

Im Prinzip reicht doch einfach, die Spalte mit der Versionsnummer als Dropdownfeld zu definieren

Wenn man sowas umsetzt ist die Anzeige wahrscheinlich nicht so trivial, da man es auch noch benutzbar gestalten muss.

So wie man es aus Access mit verknüpften Tabellen kennt :p

Access ist schon zulange her, dass habe ich verdrängt

[larsg]

Wenn man sowas umsetzt ist die Anzeige wahrscheinlich nicht so trivial, da man es auch noch benutzbar gestalten muss.

bin mir nicht sicher wie das gemeint sein soll.
also ich gehe aktuell schon davon aus, das man ein dropdownfeld "benutzbar" einbinden kann

[pandel]

@Erol
Sorry für die späte Reaktion, ich komm grad zu nix...

Ja, du hast es, soweit ich das sehe, richtig verstanden, was ich meinte. Ich wusste bis dato nicht, daß das Backend letztlich eigentlich bereits alles dafür nötige bietet. Das bedeutet ja nun, dass eine Erweiterung in diese Richtung deutlich eher denkbar wäre, als sonst.

Zum Thema interne Paketkennung:

Wenn wir das machen, dann wirds ganz schnell noch verwirrender.

Verstehe ich ehrlich gesagt nicht. Wenn ihr ne eigene Kennung verwendet, wie bspw. eine 16stellige Hex-ID, die niemand sieht, sondern die nur intern beim Import eines Pakets erstellt und systemweit weitergegeben wird, dann wäre eine ein-eindeutige Identifizierung des Pakets im gesamten weiteren Verlauf einfach. Dann brauchst du auch dieses productId-softwareversion-packagesversion Konstrukt nicht berücksichtigen... Aber gut...

Zum Thema Versionsauswahl:

Wie wäre in so einem Fall der Usecase für setup setzen? Soll dann der configed einfach mehrere productIds zeigen? Was passiert, wenn mehrere von diesen auf setup gesetzt werden? Wer entscheidet, welches wann abgearbeitet wird?

Im Prinzip reicht doch einfach, die Spalte mit der Versionsnummer als Dropdownfeld zu definieren, so dass man die gewünschte Version auswählen kann.

Da gibt es zwei Möglichkeiten: a) es lässt sich eben nur eine Version auf setup setzen (was zwar sinnig klingt, es aber nicht unbedingt sein muss, bspw. zwei Java Versionen für zwei unterschiedliche Tools auf der gleichen Maschine), oder man lässt es eben zu, installiert die hintereinander weg und überlässt dem Paketentwickler dafür zu sorgen, dass sich die Produkte auf der Maschine nicht in die Haare kriegen (was meineserachtens durchaus legitim ist, da er eh wissen sollte, was er da tut).

Lieber Gruß
Holger