El 17/03/11 13:34, Philipp Thomas escribió:

* Greg KH (gregkh@suse.de) [20110317 16:44]:

...

Do we know how many packages in Factory are going to have problems with this, or are you switching to see what it is going to be?

The mail from coolo which made me check said it where three packages in factory that are failing. I fixed one of them (schedtop) by adapting it to the v3 API, fixed the second (gnote) by making it use the v2 API and am checking the third (sfftobmp) right now.

Does it also provide some sort of symbol versioning or rather the SONAME of the library has been bumped up ? otherwise odl binaries will break anyway ... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Fri, 18 Mar 2011 13:08:30 +0100 Philipp Thomas wrote:

* Cristian Rodríguez (crrodriguez@opensuse.org) [20110317 20:52]:

...

Does it also provide some sort of symbol versioning or rather the SONAME of the library has been bumped up ?

Most parts of boost are header-only so there's no problem.

But unfortunately, boost-devel still triggers to install all the boost libs. And they don't obsolete old ones: susi:~ # rpm -qa libboost* libboost_python1_46_0-1.46.0-4.1.x86_64 libboost_iostreams1_46_0-1.46.0-4.1.x86_64 libboost_test1_46_0-1.46.0-4.1.x86_64 libboost_serialization1_46_0-1.46.0-4.1.x86_64 libboost_filesystem1_46_0-1.46.0-4.1.x86_64 libboost_signals1_46_0-1.46.0-4.1.x86_64 libboost_mpi1_46_0-1.46.0-4.1.x86_64 libboost_date_time1_46_0-1.46.0-4.1.x86_64 libboost_random1_46_0-1.46.0-4.1.x86_64 libboost_regex1_46_0-1.46.0-4.1.x86_64 libboost_graph1_46_0-1.46.0-4.1.x86_64 libboost_thread1_46_0-1.46.0-4.1.x86_64 libboost_program_options1_46_0-1.46.0-4.1.x86_64 libboost_system1_46_0-1.46.0-4.1.x86_64 libboost_wave1_46_0-1.46.0-4.1.x86_64 libboost_math1_46_0-1.46.0-4.1.x86_64 susi:~ # zypper -v up ... The following NEW packages are going to be installed: boost-license1_46_1 1.46.1-2.1 libboost_date_time1_46_1 1.46.1-2.1 libboost_filesystem1_46_1 1.46.1-2.1 libboost_graph1_46_1 1.46.1-2.1 libboost_iostreams1_46_1 1.46.1-2.1 libboost_math1_46_1 1.46.1-2.1 libboost_mpi1_46_1 1.46.1-2.1 libboost_program_options1_46_1 1.46.1-2.1 libboost_python1_46_1 1.46.1-2.1 libboost_random1_46_1 1.46.1-2.1 libboost_regex1_46_1 1.46.1-2.1 libboost_serialization1_46_1 1.46.1-2.1 libboost_signals1_46_1 1.46.1-2.1 libboost_system1_46_1 1.46.1-2.1 libboost_test1_46_1 1.46.1-2.1 libboost_thread1_46_1 1.46.1-2.1 libboost_wave1_46_1 1.46.1-2.1 But the old ones are not uninstalled. So slowly I'm accumulating lots of stuff on my harddrive which I never need. Can I help you somehow to create a boost-devel-headersonly and a boost-devel-alltheothercrap package? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Wed, 23 Mar 2011 10:49:53 +0100 Stephan Kulow wrote:

Am Mittwoch, 23. März 2011 schrieb Stefan Seyfried:

...

libboost_wave1_46_1 1.46.1-2.1

But the old ones are not uninstalled. So slowly I'm accumulating lots of stuff on my harddrive which I never need.

The openSUSE product marks old boost versions as orphans (but not yet 1.44) Remember liblzma0? :)

Well, but the liblzma disaster is the result of the terminal brokenness of the libzypp install method of using "rpm --ignore-everything" *and* uninstalling the dropped things as the first instead of last step. So no reason to not improve the libboost situation :-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am Mittwoch, 23. März 2011 schrieb Philipp Thomas:

Having newer libaries obsolete the older ones somehow voids the shared library policy that was created in order to allow the parallel instalation of different runtime lib versions. But I agree and am thinking of adding obsoletes to boost. That won't be accepted to factory. The policy is there for a reason.

Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Wed, 23 Mar 2011 11:43:51 +0100 Stephan Kulow wrote:

Am Mittwoch, 23. März 2011 schrieb Philipp Thomas:

...

Having newer libaries obsolete the older ones somehow voids the shared library policy that was created in order to allow the parallel instalation of different runtime lib versions. But I agree and am thinking of adding obsoletes to boost. That won't be accepted to factory. The policy is there for a reason.

But then we should get something that even the most primitive package managers like opkg have: / # opkg-cl |grep -B2 -A1 autoremove --force-removal-of-dependent-packages Remove package and all dependencies --autoremove Remove packages that were installed automatically to satisfy dependencies Otherwise you'll never be able to get rid of the accumulating lint under the sofa. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Wed, 23 Mar 2011 12:00:43 +0100 Cristian Morales Vega wrote:

2011/3/23 Stefan Seyfried :

...

But the old ones are not uninstalled. So slowly I'm accumulating lots of stuff on my harddrive which I never need.

It seems you want a "global cleandepsOnRemove" option in ZYpp?

Only for stuff that I did not install explicitly. something like "--autoremove" in opkg. Removes everything dependent that was autoinstalled. But nothing that was explicitly installed. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Wed, 23 Mar 2011, Stefan Seyfried wrote:

On Fri, 18 Mar 2011 13:08:30 +0100 Philipp Thomas wrote:

...

* Cristian Rodríguez (crrodriguez@opensuse.org) [20110317 20:52]:

...

Does it also provide some sort of symbol versioning or rather the SONAME of the library has been bumped up ?

Most parts of boost are header-only so there's no problem.

But unfortunately, boost-devel still triggers to install all the boost libs.

And they don't obsolete old ones:

susi:~ # rpm -qa libboost* libboost_python1_46_0-1.46.0-4.1.x86_64 libboost_iostreams1_46_0-1.46.0-4.1.x86_64 libboost_test1_46_0-1.46.0-4.1.x86_64 libboost_serialization1_46_0-1.46.0-4.1.x86_64 libboost_filesystem1_46_0-1.46.0-4.1.x86_64 libboost_signals1_46_0-1.46.0-4.1.x86_64 libboost_mpi1_46_0-1.46.0-4.1.x86_64 libboost_date_time1_46_0-1.46.0-4.1.x86_64 libboost_random1_46_0-1.46.0-4.1.x86_64 libboost_regex1_46_0-1.46.0-4.1.x86_64 libboost_graph1_46_0-1.46.0-4.1.x86_64 libboost_thread1_46_0-1.46.0-4.1.x86_64 libboost_program_options1_46_0-1.46.0-4.1.x86_64 libboost_system1_46_0-1.46.0-4.1.x86_64 libboost_wave1_46_0-1.46.0-4.1.x86_64 libboost_math1_46_0-1.46.0-4.1.x86_64

susi:~ # zypper -v up ...

The following NEW packages are going to be installed: boost-license1_46_1 1.46.1-2.1 libboost_date_time1_46_1 1.46.1-2.1 libboost_filesystem1_46_1 1.46.1-2.1 libboost_graph1_46_1 1.46.1-2.1 libboost_iostreams1_46_1 1.46.1-2.1 libboost_math1_46_1 1.46.1-2.1 libboost_mpi1_46_1 1.46.1-2.1 libboost_program_options1_46_1 1.46.1-2.1 libboost_python1_46_1 1.46.1-2.1 libboost_random1_46_1 1.46.1-2.1 libboost_regex1_46_1 1.46.1-2.1 libboost_serialization1_46_1 1.46.1-2.1 libboost_signals1_46_1 1.46.1-2.1 libboost_system1_46_1 1.46.1-2.1 libboost_test1_46_1 1.46.1-2.1 libboost_thread1_46_1 1.46.1-2.1 libboost_wave1_46_1 1.46.1-2.1

But the old ones are not uninstalled. So slowly I'm accumulating lots of stuff on my harddrive which I never need.

You can't simply obsolete library versions with a different SONAME, that would break existing users. Richard.

On Wed, 23 Mar 2011 13:42:51 +0100 (CET) Richard Guenther wrote:

On Wed, 23 Mar 2011, Stefan Seyfried wrote:

...

But the old ones are not uninstalled. So slowly I'm accumulating lots of stuff on my harddrive which I never need.

You can't simply obsolete library versions with a different SONAME, that would break existing users.

This stuff was only installed because I needed boost-devel (for the header-only stuff). Nothing else needs it. So it should not be kept forever. There are pretty primitive package managers that can do this just fine. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 25/03/11 16:48, İsmail Dönmez escribió:

zypper could just do a reverse dependency check and find orphan library packages.

It does, with zypper rm -u -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

El 25/03/11 16:47, Stefan Seyfried escribió:

On Wed, 23 Mar 2011 13:42:51 +0100 (CET) Richard Guenther wrote:

...

On Wed, 23 Mar 2011, Stefan Seyfried wrote:

...

...

But the old ones are not uninstalled. So slowly I'm accumulating lots of stuff on my harddrive which I never need.

You can't simply obsolete library versions with a different SONAME, that would break existing users.

This stuff was only installed because I needed boost-devel (for the header-only stuff). Nothing else needs it. So it should not be kept forever. There are pretty primitive package managers that can do this just fine.

This has nothing to do with the package manager really, but to the very purpose of the library packaging policy, allow different library versions to be installed in parallel. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2011/3/25 Stefan Seyfried :

On Fri, 25 Mar 2011 16:49:55 -0300 Cristian Rodríguez wrote:

...

This has nothing to do with the package manager really, but to the very purpose of the library packaging policy, allow different library versions to be installed in parallel.

Well, if we knew that the only reason they were installed is to satisfy boost-devel, then removing them would be the sensible thing to do. If somehthing or somebody else has installed them explicitly and thus might still need them, keeping them would be sensible.

opkg tracks this:

/var/lib/opkg # egrep '^(Package|Status):' status |head Package: libz Status: install ok installed Package: opkg Status: install user installed Package: busybox Status: install user installed Package: libvorbisidec Status: install ok installed Package: strace Status: install user installed

So it knows that if nothing requires libz anymore, it can autoremove it, but it will not autoremove busybox, opkg or strace.

I'm not aware that RPM can do this.

From ZYpp's /var/log/zypp/history:

2011-03-25 22:00:21|install|libgcj-devel|4.5-19.1|x86_64||oss|6e94dc2ac0f8f3724d69cd8a6f44b97029ea03c5 2011-03-25 22:04:07|install|obs-service-download_url|0.1-12.1|noarch|root@Primero|tools|0a97b517955df181ab461288e82df198386cab3775c388ec0779f9d1fc97edf2 The empty field between x86_64 and oss is equivalent to your "ok", and root@Primero is equivalent to your "user". It requires to check the full history in case a package was installed, removed and installed again, but it's there and works. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

* Stefan Seyfried [2011-03-25 23:09]:

On Fri, 25 Mar 2011 22:50:29 +0100 Cristian Morales Vega wrote:

...

...

So it knows that if nothing requires libz anymore, it can autoremove it, but it will not autoremove busybox, opkg or strace.

I'm not aware that RPM can do this.

From ZYpp's /var/log/zypp/history:

Unfortunately, that's a logfile, rotated and deleted from time to time. IMHO it would belong in the RPM database.

How can RPM know that if a package was installed to satisfy a dependency or by user intention? IMO it belongs at libzypp level, of course not in a logfile. :) Regards, Bernhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am 26.03.11 09:21, schrieb Cristian Morales Vega:

At ZYpp level it misses installs/removes directly from RPM ("rpm -e" is shorter than "zypper rm") and other package managers (Smart PM). To make it clear, I wasn't suggesting to use /var/log/zypp/history but saying that, since openSUSE 11.3, ZYpp **is** using /var/log/zypp/history for this purpose. And I don't think that specific file is "rotated and deleted from time to time" since, sure, it would break the system.

But since installing a package with RPM always mean to install it *explicitly* since RPM doesn't install something automatically to resolve dependencies, it cannot be tracked with RPM. And if removing a logfile (/var/log *is* for logfiles) breaks something, then this is a bug. Clearly. Regards, Bernhard