Michael Scherer wrote: > Le vendredi 14 juillet 2006 à 21:35 +0300, Anssi Hannula a écrit : > >>Michael Scherer wrote: >> >>>Le jeudi 13 juillet 2006 à 14:52 +0300, Anssi Hannula a écrit : >>> >>> >>>>Hi! >>>> >>>>I'm not too happy with the naming of packages right now: >>>> >>>>dkms-nvidia: kernel module package >>>>nvidia-xorg: X11 driver and tools >>>>libnvidia-xorg1: shared libraries for i586 >>>>lib64nvidia-xorg1: shared libraries for x86_64 >>>>libnvidia-xorg1-devel: static libraries and headers for i586 >>>>lib64nvidia-xorg1-devel: static libraries and headers for x86_64 >>>> >>>>dkms-ati: kernel module package >>>>ati-xorg: X11 driver and tools >>>>ati-xorg-32bit-compat: x86 compatibility for x86_64 >>>>ati-devel: static libs and headers >>>> >>>>There are a few problems with this: >>>>If the x86_64 user wishes to use some x86 OpenGL software, either from >>>>the Mandriva i586 repository or 3rd party, he needs to have another pkg >>>>(libnvidia-xorg1, ati-xorg-32bit-compat) installed to have hardware 3D >>>>acceleration. >>>>- although explained in the description, this is not immediately obvious >>>>- also, since the recent separating of i586 and x86_64 repos on PLF, >>>>libnvidia-xorg1 is on i586 media, which the user may or may not have >>>>installed on x86_64 >>>>- this is incompatible with the Mandriva Club packages, that provide all >>>>the necessary libraries in the main package. Thus when user upgrades to >>>>PLF ones, he loses x86 3D acceleration support >>>> >>>>The naming "nvidia-xorg" and "ati-xorg" doesn't sound too logical, either. >>>> >>>> >>>>I have two different proposals: >>>> >>>>dkms-nvidia: kernel module package >>>>nvidia: X11 driver, tools and libraries >>>>nvidia-devel: static libs and headers >>>> >>>>dkms-ati: kernel module package >>>>ati: X11 driver, tools and libraries >>>>ati-devel: static libs and headers >>>> >>>>This is also the scheme that Mandriva's Club packages use, and is pretty >>>>simple. In this scheme, the libs, including 32bit compatibility libs >>>>would be embedded in the main package. Thus "nvidia" would be 2MB larger >>>>than the previous "nvidia-xorg", and "ati" would be 5MB larger than the >>>>previous "ati-xorg". >>>> >>>>The other one: >>>> >>>>nvidia: metapackage requiring everything >>>>dkms-nvidia: kernel module package >>>>x11-driver-video-nvidia: X11 driver, tools and libraries >>>>nvidia-gl: GL libraries >>>>nvidia-gl-32bit-compat: 32bit GL libraries for x86_64 >>>>nvidia-devel: static libs and headers >>>> >>>>ati: metapackage requiring everything >>>>dkms-ati: kernel module package >>>>x11-driver-video-fglrx: X11 driver, tools and libraries >>>>ati-gl: GL libraries >>>>ati-gl-32bit-compat: 32bit GL libraries for x86_64 >>>>ati-devel: static libs and headers >>>>(the control panel could also be separated, as it requires qt3 etc) >>>> >>>>Here Club compatibility is also preserved, but we have split the pkg to >>>>smaller chunks. This allows the user to (1) not install 32bit-compat if >>>>he doesn't want to and (2) install a driver without the hardware 3d stuff. >>>> >>>> >>>>People, please tell me what would you prefer? >>>> >>>>I like the first one (Club scheme) more, as IMHO the latter one is too >>>>complicated for very little gain. >>> >>> >>>I prefer the second one, isn't there some deps that would be pulled by >>>ati-gl-32bit-compat ? ( now or maybe in the future ). >> >>By default (ati|nvidia)-gl-32bit-compat would pull libx11_6 and libxext6 >>for libX11.so.6 and libXext.so.6 (libxorg-x11 on 2006.0). >> >>We could have a _requires_exceptions however, as these will be pulled >>anyway by the 32bit software that the user wishes to use. > > > if the software is packaged as a rpm, of course > > > >>Club ati package doesn't seem to have _requires_exceptions, it will pull >>32bit libxorg-x11 on x86_64 too. >> >>I was thinking that the "ati" metapackage could pull this package (named >>ati-gl-32bit-compat or libati-gl1), do you agree with that? > > > Yes. > I really think people should learn that running 32 bits packages > requires 32 bits rpm sources. >
Well, the problem here is that even if they had 32bit sources, they may not realize that they need this 32bit-compat package as it is not pulled by anything. > >>Or do you think the current method of providing a notification in the >>main pkg description is enough? >>"To enable the NVIDIA hardware OpenGL acceleration also for 32bit >>applications you should install the package libnvidia-xorg1 too." > > > no, i doubt, as people never read docs :) > > > >>>And, is there a reason to not follow library naming policy, except the >>>fact that mandriva club do not follows it ? BTW, one reason (probably not good enough, though) to have the all-in-one driver package like club has is the fact that it can be reverted more easily. There are sometimes regressions introduced, and it is a lot easier to remove/revert just two packages than six, which don't even have simple names. Another reason against the library naming policy is that it doesn't bring any advantages in this case: the libraries won't be required by other packages, nor it is useful to install the i586 libs on x86_64. >> >>Well... ati has 3 libGL.so.1 libraries: >>1. 32-bit one (not usable on 64-bit host) >>2. 64-bit one >>3. 32-bit wrapper for 64-bit hosts >> >>So we would end up having libati-gl1.i586.rpm, lib64ati-gl1.x86_64.rpm, >>libati-gl1.x86_64.rpm? >> >>If that's preferable, it is doable. >> >>For nvidia there are only 2 libGL.so.1 libraries: >>1. 32-bit one, also usable as a wrapper on 64-bit host >>2. 64-bit one >> >>However, currently the libnvidia-xorg1 is shipped only on i586 PLF >>media. I'm not sure if that's a good idea, as for example i586 >>libxorg-x11 is shipped on Mandriva x86_64 medias too. > > > not in cooker, or it was changed ? > I think it is due to the fact OpenOffice depend on it as a 32 bits > application, so this may be removed in a near future, if oo is compiled > on x86_64 Oh. I don't know what I was thinking when I wrote that. The real reason is that we want to require it by the metapackage, and we can't do that if it's in the i586 repo. > >> So I'd like to >>have the 32-bit nvidia GL lib in a x86_64 pkg too. >>The ati and nvidia packaging schemes would then be similar. >> >>The tool libraries (libnvidia-tls.so.1, libnvidia-cfg.so.1, >>libfglrx_gamma.so.1, libfglrx_pp.so.1, libfglrx_dm.so.1) could be put to >>their own package following the lib naming policy, though. I think I'll >>do that. >> >>So maybe like this? >> >>nvidia: metapackage requiring everything >>dkms-nvidia: kernel module package >>x11-driver-video-nvidia: X11 driver >>nvidia-tools Control panel and command line tools >>lib64nvidia-gl1: GL libraries (on x86_64 only) >>libnvidia-gl1: GL libraries (on *both* i586 and x86_64) >>lib64nvidia1 Other libraries than GL (XVMC etc) >>lib64nvidia1-devel: static XVMC library and GL headers >> >> >>ati: metapackage requiring everything >>dkms-ati: kernel module package >>x11-driver-video-fglrx: X11 driver >>ati-tools Control panel and command line tools >>lib64ati-gl1: GL libraries (on x86_64 only) >>libati-gl1: GL libraries (on *both* i586 and x86_64) >>lib64ati1 Other libraries than GL (dm, gamma, pp) >>lib64ati1-devel: static libs, GL headers, gamma header > > > this one is ok for me, as long as lib$DRIVER-gl1 is only pulled by the > meta package. Some people prefer having only 64 bits packages. > > And i think we should avoid exception for naming, as we may rely on it > for various things. >>>>If you have something else to suggest, please do so. >>> >>> > -- Anssi Hannula _______________________________________________ PLF-discuss mailing list [email protected] https://www.zarb.org/mailman/listinfo/plf-discuss
