Dear Robert, dear listmembers, AFAIK the modules that are used for this are packaged as binaries in rpm-containers (i. e. like slmodem or wlan - modules). If the ABI would change, those packages would have to be upgraded anyway and SUSE would be urged to provide the corresponding packages in conjunction with such a major kernel upgrade. Though I agree that the naming I coose is probably not optimal as these modules are not "persistent" by themselfes, the persistence will last as long as the ABI compatibility will last. But this in turn gives persistence and therefore I still think to use "persistence" in the name is not the worst choice in this regard. Therefore I do not agree entirely with Roberts arguments. These modules belong to 2.6.18.2 in the same way as they belong to 2.6.18.8 or any other 2.6.X kernel that keeps this part of the ABI constant. From what I have learned they are not initially related to 2.6.18.2. IMHO it is only bad to refer to names of components that are not used any more in your system (what is true in the very moment you do upgrade now). Spoken from experience I can hardly remember a SUSE distribution that did not upgrade the kernel at some point in time. So I'd say this is something that should be expected. In a "generic" sense it would be best to start with soft-linked modules from the very begin of a distribution, what is in tune with my statement. And one could remove the reference to the individual kernel entirely: Call the directory /lib/modules/persistent from the very begin. Maybe one would like to use persistent-default / persistent-bigsmp. Put in all module-binaries that stem from non-kernel-rpms (i.e. wlan<something>.rpm or slmodem<something>.rpm). Start with linking those into the appropriate kernel-module directories from the very begin. Whenever the abi changes, one must change / upgrade the packages anyway - there is no harm in this case, the package manager and the dependency rules have to prevent from errors here. The container of those packages would never refer to a kernel that came out of use. Take care Dieter Jurzitza -- ________________________________________________ HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Mobile: +49 0151 - 16 339 017 Fax: +49 (0)7248 71-1216 eMail: DJurzitza@harmanbecker.com Internet: http://www.becker.de
-----Ursprüngliche Nachricht----- Von: Robert Schiele [mailto:rschiele@gmail.com] Gesendet: Dienstag, 20. März 2007 09:40 An: Jurzitza, Dieter Cc: opensuse-packaging@opensuse.org Betreff: Re: [opensuse-packaging] problematic new path naming structure
Feel free to suggest a better scheme but only suggest a scheme that actually does _work_.
******************************************* Harman Becker Automotive Systems GmbH Geschaeftsfuehrung: Dr. Peter Geiselhart - Michael Mauser - William S. Palin - Edwin Summers - Regis Baudot Sitz der Gesellschaft: Karlsbad - Registergericht: Mannheim HRB 361395 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org