[opensuse-factory] Dist Meeting 2007-07-05
Sorry for the late email, we plan to discuss later today the following topics in our distribution meeting: * FreeNx: use of /usr/NX FreeNX and NX use /usr/NX and this is the upstream default for NX packages by Nomachine. But /usr/NX which is not allowed by the FHS. Reworking the package is a major problem. What should be done? * Handling of dropped packages: Most update problems Thorsten run into in the last time happend, because of: We dropped packages, but nobody make sure that this package and _all_ subpackages and _all_ xxbit (meaning 32bit/64bit) packages will be removed from the installed system ("successor"). On openSUSE, this happend during Systemupdate with the YaST2 option "remove no longer available packages". But with different Add-On Products, channels and other products from Novell, this is no option for the Enterprise products, and it becomes more and more a problem for openSUSE, too. So, if a package is dropped in autobuild, we need to make sure that: - All subpackages and xxbit packages are dropped somehow by other RPMs, too. Or this package has only limited dependencies, which will NEVER change in the feature. For example it has only dependencys to libc. Dependencies for openssl for example are already bad again, because that interface will change and customer will run in update problems. - We have a successor for all main and subpackages. The same is true for package renames, package splits, and so on. With the current renameing inflation because of the library naming policy, a lot of people forget to handle all subpackages correct, and we have left overs like -devel or -xxbit packages, which breaks the solver. * Improve debuginfo packages To get a complete stack trace, we need several debuginfo packages. The simple idea would be to copy dependencies from the main package to the debuginfo package. But this would give too many dependencies since it would lead to include always the gcc-debuginfo package (currently 300 MB). Another idea is to reduce the size of debuginfo packages and mark them only for backtrace - with removing the source code. Any comments, ideas, suggestions? Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
* Andreas Jaeger <aj@suse.de> [2007-07-05 09:09]:
* Improve debuginfo packages
To get a complete stack trace, we need several debuginfo packages. The simple idea would be to copy dependencies from the main package to the debuginfo package. But this would give too many dependencies since it would lead to include always the gcc-debuginfo package (currently 300 MB).
Another idea is to reduce the size of debuginfo packages and mark them only for backtrace - with removing the source code.
But then I'd be for not removing the source code debug packages but split into -debuginfo and -debuginfo-source, for example. However, why not copying just the dependencies with a few exception, e.g. the gcc-debuginfo that you mentioned? Thanks, Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag 05 Juli 2007 schrieb Bernhard Walle:
But then I'd be for not removing the source code debug packages but split into -debuginfo and -debuginfo-source, for example.
However, why not copying just the dependencies with a few exception, e.g. the gcc-debuginfo that you mentioned?
Just to give some data - so that further 300MB misinformations do not spread (might be different for other architectures of course). Few of these are dependencies of other packages. 1,9G OpenOffice_org-debuginfo-2.2.99.211-3.i586.rpm 218M kernel-debug-debuginfo-2.6.22_rc7-2.i586.rpm 216M kernel-bigsmp-debuginfo-2.6.22_rc7-2.i586.rpm 216M kernel-default-debuginfo-2.6.22_rc7-2.i586.rpm 215M kernel-vanilla-debuginfo-2.6.22_rc7-2.i586.rpm 201M kernel-kdump-debuginfo-2.6.22_rc4-2.i586.rpm 197M kernel-xenpae-debuginfo-2.6.22_rc7-2.i586.rpm 197M kernel-xen-debuginfo-2.6.22_rc7-2.i586.rpm 173M kdepim4-debuginfo-3.90.1.svn679144-3.i586.rpm 151M kdebase4-debuginfo-3.90.1.svn679137-3.i586.rpm 138M libqt4-debuginfo-4.3.0-11.i586.rpm 137M kdepim3-debuginfo-3.5.7-16.i586.rpm 108M kdelibs4-debuginfo-3.90.1.svn678422-3.i586.rpm 98M seamonkey-debuginfo-1.1.2-5.i586.rpm 92M kdevelop3-debuginfo-3.4.1-18.i586.rpm 89M koffice-debuginfo-1.6.3-2.i586.rpm 88M rekall-debuginfo-2.4.5-37.i586.rpm 81M MozillaThunderbird-debuginfo-2.0.0.4-4.i586.rpm 76M kdesdk4-debuginfo-3.90.1.svn679147-3.i586.rpm 75M MozillaFirefox-debuginfo-2.0.0.4-12.i586.rpm 74M kdenetwork4-debuginfo-3.90.1.svn679956-4.i586.rpm 74M mozilla-xulrunner181-debuginfo-1.8.0.99-84.i586.rpm 73M MozillaSunbird-debuginfo-0.3-61.i586.rpm 66M wxGTK-debuginfo-2.8.4.0-17.i586.rpm 63M kdeedu4-debuginfo-3.90.1.svn678988-3.i586.rpm 63M gcc42-debuginfo-4.2.1_20070628-2.i586.rpm 62M kdebase3-debuginfo-3.5.7-26.i586.rpm 61M kernel-um-debuginfo-2.6.22_rc7-2.i586.rpm 57M nvu-debuginfo-1.0-67.i586.rpm 57M boson-debuginfo-0.13-77.i586.rpm Splitting out -source I guess is possible, but I wonder how to find out dependencies. Because I think we lack the information that libgcc_s.so's debuginfo is to be found in gcc42-debuginfo. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 5 Jul 2007, Bernhard Walle wrote:
* Andreas Jaeger <aj@suse.de> [2007-07-05 09:09]:
* Improve debuginfo packages
To get a complete stack trace, we need several debuginfo packages. The simple idea would be to copy dependencies from the main package to the debuginfo package. But this would give too many dependencies since it would lead to include always the gcc-debuginfo package (currently 300 MB).
Another idea is to reduce the size of debuginfo packages and mark them only for backtrace - with removing the source code.
But then I'd be for not removing the source code debug packages but split into -debuginfo and -debuginfo-source, for example.
However, why not copying just the dependencies with a few exception, e.g. the gcc-debuginfo that you mentioned?
I would instead simply drop the source by default and provide a script to unpack a source rpm at the place of the debuginfo sources. For selected packages we might ship diffs from the original sources to the compiled ones, but I doubt it matters for anything but glibc and the kernel. Richard. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Andreas Jaeger <aj@suse.de> [Jul 05. 2007 09:09]:
* Handling of dropped packages:
Most update problems Thorsten run into in the last time happend, because of:
We dropped packages, but nobody make sure that this package and _all_ subpackages and _all_ xxbit (meaning 32bit/64bit) packages will be removed from the installed system ("successor").
On openSUSE, this happend during Systemupdate with the YaST2 option "remove no longer available packages". But with different Add-On Products, channels and other products from Novell, this is no option for the Enterprise products, and it becomes more and more a problem for openSUSE, too.
So, if a package is dropped in autobuild, we need to make sure that: - All subpackages and xxbit packages are dropped somehow by other RPMs, too.
Dropping packages usually means one of two things 1. functionality is now available by another package 2. functionality is removed Case 1 is the 'package merge" case as documented at http://en.opensuse.org/Upgrade_Dependencies#Merging_a_package The means to express this is via the 'Obsoletes' dependency. Case 2 is the hard one, since there is no package 'taking over', thus no clear place to put the 'Obsoletes' dependency. I do not see any other solution than to handle such cases in the installer. The dependencies of the new product (resp. the new 'core' pattern) could handle the needed 'Obsoletes'.
Or this package has only limited dependencies, which will NEVER change in the feature. For example it has only dependencys to libc. Dependencies for openssl for example are already bad again, because that interface will change and customer will run in update problems.
This sounds like the package is left installed but effectively is abandoned. In this case, the user still should be informed about the 'leftover' as it is no longer maintained.
- We have a successor for all main and subpackages.
The same is true for package renames, package splits, and so on. With the current renameing inflation because of the library naming policy, a lot of people forget to handle all subpackages correct, and we have left overs like -devel or -xxbit packages, which breaks the solver.
This should be catchable in buildservice/autobuild. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (5)
-
Andreas Jaeger -
Bernhard Walle -
Klaus Kaempf -
Richard Guenther -
Stephan Kulow