[opensuse-packaging] Coping with the recent Boost update
Boost 1.46.0 was checked into factory not long ago (and will get an update to 1.46.1 in the next days). The main change that wasn't mentioned in the changes and thus escaped me was that beginning with 1.46.0 boost::filesystem will switch its default API from v2 to v3 (see http://www.boost.org/doc/libs/1_46_1/libs/filesystem/v3/doc/index.htm). This will cause packages that use boost::filesystem and that don't support v3 to fail. There are three possible ways to fix the breakage: 1) Adapt the code to work with v3 2) Adapt the code to work with v2 or v3 3) Let the code use the v2 API. The last one is the easiest but the v2 API will go with 1.48. The changes in the API are described in http://www.boost.org/doc/libs/1_46_1/libs/filesystem/v3/doc/deprecated.html. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Mar 17, 2011 at 04:27:02PM +0100, Philipp Thomas wrote:
Boost 1.46.0 was checked into factory not long ago (and will get an update to 1.46.1 in the next days). The main change that wasn't mentioned in the changes and thus escaped me was that beginning with 1.46.0 boost::filesystem will switch its default API from v2 to v3 (see http://www.boost.org/doc/libs/1_46_1/libs/filesystem/v3/doc/index.htm). This will cause packages that use boost::filesystem and that don't support v3 to fail.
There are three possible ways to fix the breakage: 1) Adapt the code to work with v3 2) Adapt the code to work with v2 or v3 3) Let the code use the v2 API.
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? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* 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. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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
* 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. And those parts that need compiled libraries have the full version number in their SONAMES i.e. each version is binary incompatible. So there can be no breaking binaries. Philipp -- 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 <pth@suse.de> 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
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? :) 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 10:49:53 +0100 Stephan Kulow <coolo@suse.de> 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
* Stefan Seyfried (stefan.seyfried@googlemail.com) [20110323 10:26]:
But unfortunately, boost-devel still triggers to install all the boost libs.
Yepp. Patches that split up the boost source code will gladly be accepted though :)
But the old ones are not uninstalled. So slowly I'm accumulating lots of stuff on my harddrive which I never need.
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.
Can I help you somehow to create a boost-devel-headersonly and a boost-devel-alltheothercrap package?
If you want to delve into the details of boost::build and the Jamfiles I won't stand in the way :) But note that zypper uses boost::filesystem and if you do such a change the zypper folks should be notified of the change. Philipp -- 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
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.
What about those "weakremover" provides in openSUSE-release? They seem be some kind of weak obsoletes. Is the mechanism documented somewhere? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- 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 <coolo@suse.de> 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
2011/3/23 Stefan Seyfried <stefan.seyfried@googlemail.com>:
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? -- 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 <cmorve69@yahoo.es> wrote:
2011/3/23 Stefan Seyfried <stefan.seyfried@googlemail.com>:
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
2011/3/25 Stefan Seyfried <stefan.seyfried@googlemail.com>:
On Wed, 23 Mar 2011 12:00:43 +0100 Cristian Morales Vega <cmorve69@yahoo.es> wrote:
2011/3/23 Stefan Seyfried <stefan.seyfried@googlemail.com>:
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.
cleandepsOnRemove option already takes that into account (looking at /var/log/zypp/history, IMHO it should be in RPM itself, making easy to change the state if needed; and bnc#679213)
something like "--autoremove" in opkg. Removes everything dependent that was autoinstalled. But nothing that was explicitly installed.
ZYpp already does that, but only for removes (or any operation that needs something to be removed?). I also miss the global option... -- 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 <pth@suse.de> 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.
El 23/03/11 09:42, Richard Guenther escribió:
You can't simply obsolete library versions with a different SONAME, that would break existing users.
Exactly, breaking one of the purposes of this policy. So in short, libfoo2 should NOT obsolete libfoo1 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 23 Mar 2011 13:42:51 +0100 (CET) Richard Guenther <rguenther@suse.de> 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
Hi; On Fri, Mar 25, 2011 at 8:47 PM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
On Wed, 23 Mar 2011 13:42:51 +0100 (CET) Richard Guenther <rguenther@suse.de> 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.
zypper could just do a reverse dependency check and find orphan library packages. ismail -- 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
Hi; On Fri, Mar 25, 2011 at 8:50 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
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
Problem solved then ;) ismail -- 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 <rguenther@suse.de> 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
On Fri, 25 Mar 2011 16:49:55 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> 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. -- 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
2011/3/25 Stefan Seyfried <stefan.seyfried@googlemail.com>:
On Fri, 25 Mar 2011 16:49:55 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> 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
On Fri, 25 Mar 2011 22:50:29 +0100 Cristian Morales Vega <cmorve69@yahoo.es> 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. -- 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
* Stefan Seyfried <stefan.seyfried@googlemail.com> [2011-03-25 23:09]:
On Fri, 25 Mar 2011 22:50:29 +0100 Cristian Morales Vega <cmorve69@yahoo.es> 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
2011/3/26 Bernhard Walle <bernhard@bwalle.de>:
* Stefan Seyfried <stefan.seyfried@googlemail.com> [2011-03-25 23:09]:
On Fri, 25 Mar 2011 22:50:29 +0100 Cristian Morales Vega <cmorve69@yahoo.es> 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. :)
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. Anyway, if someone wants this to be changed he should submit a patch, open a bug report, or at least discuss this in zypp-devel, not in opensuse-packaging. When libzypp 7.4 was released I asked about this (http://lists.opensuse.org/zypp-devel/2010-05/msg00002.html), but since nobody else asked I supposed I was the only one interested. -- 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
On Sat, 26 Mar 2011 09:21:15 +0100 Cristian Morales Vega <cmorve69@yahoo.es> wrote:
2011/3/26 Bernhard Walle <bernhard@bwalle.de>:
How can RPM know that if a package was installed to satisfy a dependency
That's a good point. Missed that. But assuming somehting installed by "rpm -i" always is explicitly wanted, not by dependency would be OK.
or by user intention? IMO it belongs at libzypp level, of course not in a logfile. :)
Libzypp could still store it in the rpm database...
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 the info available to other package managers.
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.
seife@susi:~> ls -l /var/log/zypp total 4320 -rw-r--r-- 1 root root 3419395 Mar 25 22:38 history -rw-r--r-- 1 root root 445160 Jun 14 2010 history-20100614.bz2 -rw-r--r-- 1 root root 552750 Oct 9 22:58 history-20101010.bz2
Anyway, if someone wants this to be changed he should submit a patch, open a bug report, or at least discuss this in zypp-devel, not in opensuse-packaging. When libzypp 7.4 was released I asked about this (http://lists.opensuse.org/zypp-devel/2010-05/msg00002.html), but since nobody else asked I supposed I was the only one interested.
Well, yet another mailinglist for a topic I'm not really interested in, no. I'm not going to do that. But yes factory would have been the more appropriate list. I'll complain there once the next boost update hits us ;-) -- 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
participants (10)
-
Bernhard Walle -
Cristian Morales Vega -
Cristian Rodríguez -
Greg KH -
İsmail Dönmez -
Ludwig Nussel -
Philipp Thomas -
Richard Guenther -
Stefan Seyfried -
Stephan Kulow