[opensuse-factory] Meeting Minutes Dist Meeting 2007-05-10
Here're the minutes from the last meeting, Andreas * dbus restart Restarting of d-bus needs special handling in every package, otherwise they might crash. Upstream d-bus maintainer currently say that d-bus should not get restarted. The long-term goal is that all applications and services should handle d-bus restarts gracefully. For the short term, we will advice the user to reboot the system and not automatically restart d-bus during package updates. * Moving d-bus to / This is need for some potential changes in hal. Since we did not have enough details, we decided to stay for now with the default and rediscuss when needed. * Shared library policy see: http://en.opensuse.org/Shared_Library_Packaging_Policy If nobody raises objections, we'll move forward with it and add it to the packagers manual. Note: This is not enforced for existing packages. It should be done for major updates and must be done for new package submissions. AI: everybody to read and comment on opensuse-packaging mailing list. * 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. We run out of time and will discuss this further next time. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ 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
On Saturday 12 May 2007 17:02:17 Andreas Jaeger wrote:
We run out of time and will discuss this further next time.
Was topic "Smaller systems - what can be done?" not discussed because of this? Bye, Steve --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stephan Binner <stbinner@suse.de> writes:
On Saturday 12 May 2007 17:02:17 Andreas Jaeger wrote:
We run out of time and will discuss this further next time.
Was topic "Smaller systems - what can be done?" not discussed because of this?
We discussed it but there was nothing new for the minutes besides some internal discussions for released products, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ 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 wrote:
* Shared library policy see: http://en.opensuse.org/Shared_Library_Packaging_Policy
If nobody raises objections, we'll move forward with it and add it to the packagers manual.
I would raise several objection: 0) Static only packages 1) Packages with some devel files in the main package. If package is static only or package provides devel files (e. g. .pc file) without splitting -devel package, it must provide -devel package, either as a virtual symbol or as a package (by skipping of file list of the main package). Packages linking against the library or referring devel files from the package (e. g. .pc files), must refer to foo-devel, not foo. It allows painless move to shared library and painless splitting in future. Example: package foo with static-only stuff: Provides: %{name}-devel = %{version}-%{release} Real life example: Package check moved from static to shared library after 10.2. Several other packages were splitted. Both raised need to adopt many other packages. 2) Naming of devel package. This is bad proposal, at least for packages using pkgconfig to refer to their libraries. These libraries can use arbitrary soname without breaking API (but breaking soname ABI). Example: We have package libgsf with libgsf-1.so.114 and libgsf-1.pc. Naming package libgsf114-devel is a pure nosense, because: - If the next version will be named libgsf-1.so.115, libgsf115-devel will most probably conflict with libgsf114-devel anyways. - Packages searching for API-compatible libgsf114-devel will fail. - When new branch will be created, it will get name libgsf-2.so.0, so this rule will "upgrade" to libgsf0-devel. So my proposal: Shared library package should be named libgsf1_114, but devel package should be named libgsf1. If more than one version of a -devel package can be installed at the same time (for example because includes are packaged in a versioned directory and shared libraries have a versioned name like libgtk1.so.1) the -devel packages should be suffixed with the same number as the shared library package, lib$NAME$NUM-devel. -devel packages should have another number, which should be deduced from pkgconfig name. If we will not do it, similar problem as soname one problem will remain for devel packages. Proposal was sent a year ago: If package allows installation of more devel versions at once or we decided to provide more conflicting devel packages in one OpenSUSE version and pkgconfig files use numbers, which The proble here is real and we have hacks in Build Service to fix version compatibility. devel package should be named libgsf1, package itself probably libgsf1_114. #!/bin/bash function propose_package_name { echo -n $1 | sed 's/[0-9]*$//' echo $(rpm -ql $1{,-devel} 2>/dev/null | grep '\.pc$' | sed 's/.*[^0-9.]\([0-9.]*\)\.pc/\1/;:1;s/\.0$//;t1;s/\.//g' | sort -u) } for PACKAGE in "$@" ; do propose_package_name "$PACKAGE" done 3) Shared library for more packages. - There is no reason why a -devel package cannot provide development files for multiple shared library packages. Yes, in particular cases there it is: If shared library packages are: avahi, avahi-glib, avahi-qt3, avahi-qt4 and you will create only one avahi-devel, you must logically add Requires for all four upper mentioned packages. It will unintentionally introduce need of installation of qt3-devel and qt4-devel, even if you want to compile only against glib. 4) Missing rule: Devel package dependency chain. Devel package dependency chain should be complete and no package should be missing. If you install this package, it must depend on all needed packages for pkg-config, libtool, #include and symlink targets. foo-devel package must require foo, either explicitly or implicitly, if it is needed for development. There is not yet any tool for automatic collecting of devel dependencies, but I am thinking about a tool collecting packages from .pc files and #include. Preferred way to do it: Requires: %{name} = %{version} 5) Missing rule: How to call ldconfig (It's probably already in packagers manual.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stanislav Brabec <sbrabec@suse.cz> writes:
Andreas Jaeger wrote:
* Shared library policy see: http://en.opensuse.org/Shared_Library_Packaging_Policy
If nobody raises objections, we'll move forward with it and add it to the packagers manual.
I would raise several objection:
0) Static only packages 1) Packages with some devel files in the main package.
If package is static only or package provides devel files (e. g. .pc file) without splitting -devel package, it must provide -devel package, either as a virtual symbol or as a package (by skipping of file list of the main package).
Packages linking against the library or referring devel files from the package (e. g. .pc files), must refer to foo-devel, not foo.
It allows painless move to shared library and painless splitting in future.
Example: package foo with static-only stuff: Provides: %{name}-devel = %{version}-%{release}
Real life example: Package check moved from static to shared library after 10.2. Several other packages were splitted. Both raised need to adopt many other packages.
So, what is your objection here?
2) Naming of devel package.
This is bad proposal, at least for packages using pkgconfig to refer to their libraries. These libraries can use arbitrary soname without breaking API (but breaking soname ABI).
Example: We have package libgsf with libgsf-1.so.114 and libgsf-1.pc.
Naming package libgsf114-devel is a pure nosense, because:
- If the next version will be named libgsf-1.so.115, libgsf115-devel will most probably conflict with libgsf114-devel anyways.
- Packages searching for API-compatible libgsf114-devel will fail.
- When new branch will be created, it will get name libgsf-2.so.0, so this rule will "upgrade" to libgsf0-devel.
So my proposal:
Shared library package should be named libgsf1_114, but devel package should be named libgsf1.
If more than one version of a -devel package can be installed at the same time (for example because includes are packaged in a versioned directory and shared libraries have a versioned name like libgtk1.so.1) the -devel packages should be suffixed with the same number as the shared library package, lib$NAME$NUM-devel.
-devel packages should have another number, which should be deduced from pkgconfig name. If we will not do it, similar problem as soname one problem will remain for devel packages.
Proposal was sent a year ago: If package allows installation of more devel versions at once or we decided to provide more conflicting devel packages in one OpenSUSE version and pkgconfig files use numbers, which
The proble here is real and we have hacks in Build Service to fix version compatibility.
devel package should be named libgsf1, package itself probably libgsf1_114.
#!/bin/bash function propose_package_name { echo -n $1 | sed 's/[0-9]*$//' echo $(rpm -ql $1{,-devel} 2>/dev/null | grep '\.pc$' | sed 's/.*[^0-9.]\([0-9.]*\)\.pc/\1/;:1;s/\.0$//;t1;s/\.//g' | sort -u) } for PACKAGE in "$@" ; do propose_package_name "$PACKAGE" done
3) Shared library for more packages.
- There is no reason why a -devel package cannot provide development files for multiple shared library packages.
Yes, in particular cases there it is:
If shared library packages are: avahi, avahi-glib, avahi-qt3, avahi-qt4 and you will create only one avahi-devel, you must logically add Requires for all four upper mentioned packages. It will unintentionally introduce need of installation of qt3-devel and qt4-devel, even if you want to compile only against glib.
4) Missing rule: Devel package dependency chain.
Devel package dependency chain should be complete and no package should be missing. If you install this package, it must depend on all needed packages for pkg-config, libtool, #include and symlink targets.
foo-devel package must require foo, either explicitly or implicitly, if it is needed for development.
There is not yet any tool for automatic collecting of devel dependencies, but I am thinking about a tool collecting packages from .pc files and #include.
Preferred way to do it: Requires: %{name} = %{version}
And how can we get rid of these later again? We currently have a lot of packages with too many dependencies ;-(
5) Missing rule: How to call ldconfig
(It's probably already in packagers manual.)
I hope so ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ 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
participants (3)
-
Andreas Jaeger -
Stanislav Brabec -
Stephan Binner