[opensuse-packaging] problematic new path naming structure
Dear Robert, dear listmembers,
Call the directory /lib/modules/persistent from the very begin. Maybe one would like to use persistent-default / persistent-bigsmp.
This does not work because it does not allow installation of multiple kernels with different ABIs. well, how would this work right now? The packages provided binary are provided for one single kernel, probably for default / bigsmp, that's about it.
The question is: why make the majority of people using a single kernel configuration suffer from a somewhat exotic concept of people using different kernels in parallel (rumor on the list ;-))? In my understanding the SuSE concept is straightforward and monolithic to a certain point: you get a kernel with the distribution, you use it, you may upgrade "in line", but just try to upgrade from i.e. 2.6.11 to 2.6.13, a decent part of things like the automount functionality (among other discrepancies) is gone because things do not match any more. If you want to do what you suggest you will have to rebuild all the kernel module extra packages from scratch for the new kernel anyway, no improvement here. The current concept does not work for this either. I can only support what Herbert Graeber said. But as initially stated, these are just my 2 cents here :-). We won't solve the issue here. Take care Dieter -- ________________________________________________ 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 15:44 An: Jurzitza, Dieter Cc: opensuse-packaging@opensuse.org Betreff: Re: [opensuse-packaging] problematic new path naming structure
Though I agree that the naming I coose is probably not optimal as these modules are not "persistent" by themselfes, the
On Tue, Mar 20, 2007 at 02:03:48PM +0100, Jurzitza, Dieter wrote: 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.
This is not about the name of the directory but about whether it does work or not.
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.
I don't think that it is important whether you agree with me or not as long as you propose to replace a system that works with another system that does not work.
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.
This does not work because it does not allow installation of multiple kernels with different ABIs.
Robert
-- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
******************************************* 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
On Tue, Mar 20, 2007 at 04:47:02PM +0100, Jurzitza, Dieter wrote:
Dear Robert, dear listmembers,
Call the directory /lib/modules/persistent from the very begin. Maybe one would like to use persistent-default / persistent-bigsmp.
This does not work because it does not allow installation of multiple kernels with different ABIs. well, how would this work right now? The packages provided binary are provided for one single kernel, probably for default / bigsmp, that's about it.
You just install one package for each kernel you need this module for. It's that simple. Nothing magic about that.
The question is: why make the majority of people using a single kernel configuration suffer from a somewhat exotic concept of people using different kernels in parallel (rumor on the list ;-))?
Nobody really suffers from the current situation. It's just that you don't like it the way it works now but until now you didn't provide a reasobable argument that something else is better.
In my understanding the SuSE concept is straightforward and monolithic to a certain point: you get a kernel with the distribution, you use it, you may upgrade "in line", but just try to upgrade from i.e. 2.6.11 to 2.6.13, a decent part of things like the automount functionality (among other discrepancies) is gone because things do not match any more.
Well, you can just keep the old version for safety reasons, just for the case something breaks when booting the new kernel.
If you want to do what you suggest you will have to rebuild all the kernel module extra packages from scratch for the new kernel anyway, no improvement here. The current concept does not work for this either.
No. It seems you just did not understand how the whole kmp packaging system works. I'd suggest you read the white paper about it.
I can only support what Herbert Graeber said. But as initially stated, these are just my 2 cents here :-). We won't solve the issue here.
There is no real problem and thus there is nothing to solve. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
participants (2)
-
Jurzitza, Dieter
-
Robert Schiele