[opensuse-factory] RPM 4.9.0 and needed changes in spec files
Since I got no answer in -packaging (http://lists.opensuse.org/opensuse-packaging/2011-03/msg00050.html) trying here. What's the plan for RPM in openSUSE 12.1? RPM 4.9.0 was released nearly two month ago and Factory still uses 4.8, I would rather prefer to start adapting the spec files now than later. I suppose Vincent continues modifying spec files with his new macros, it would be ugly to say him all the work needs to be undone at the last moment. The first step would be informing packagers of any new rules. Looking at the release notes I see two important points: * "Dependency generators are now pluggable. Arbitrary number of dependency types is supported, new types can be added through a drop-in directory and file classification is now done with a combination of path and libmagic-type include/exclude regular expressions (XXX add link to documentation once it exists)" How they exactly work? Something should be changed about %wx_requires? * "EXPERIMENTAL support for package "collections" which are sort of like named triggers that only run once within a transaction. This can be used for example to avoid redundant calls for cache updates etc. (XXX add link to documentation once it exists)" Experimental? Should we use this instead of multiple calls to gtk-update-icon-cache? It's expected that openSUSE 12.1 will use a newer RPM where collections are no longer experimental? And this would be nice: * "Short-circuiting binary builds is now allowed by rpmbuild for developer convenience while testing. Short-circuited packages are tainted with an unsatisfiable dependency to limit their use for the intended testing-only purpose." How? Is this possible through "osc build"? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Apr 25, 2011 at 03:41:23PM +0200, Cristian Morales Vega wrote:
What's the plan for RPM in openSUSE 12.1? RPM 4.9.0 was released nearly two month ago and Factory still uses 4.8, I would rather prefer to start adapting the spec files now than later. I suppose Vincent continues modifying spec files with his new macros, it would be ugly to say him all the work needs to be undone at the last moment.
12.1 will have rpm-4.9.x.
The first step would be informing packagers of any new rules. Looking at the release notes I see two important points:
* "Dependency generators are now pluggable. Arbitrary number of dependency types is supported, new types can be added through a drop-in directory and file classification is now done with a combination of path and libmagic-type include/exclude regular expressions (XXX add link to documentation once it exists)"
How they exactly work? Something should be changed about %wx_requires?
AFAIK this only works for the internal generator, which we don't use for a couple of reasons. I'll try to port it to the external generator.
* "EXPERIMENTAL support for package "collections" which are sort of like named triggers that only run once within a transaction. This can be used for example to avoid redundant calls for cache updates etc. (XXX add link to documentation once it exists)"
Experimental? Should we use this instead of multiple calls to gtk-update-icon-cache? It's expected that openSUSE 12.1 will use a newer RPM where collections are no longer experimental?
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
And this would be nice:
* "Short-circuiting binary builds is now allowed by rpmbuild for developer convenience while testing. Short-circuited packages are tainted with an unsatisfiable dependency to limit their use for the intended testing-only purpose."
How? Is this possible through "osc build"?
It's just a option that needs to be passed to rpmbuild, so maybe osc build doesn't need to be changed. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mardi 26 avril 2011, à 11:46 +0200, Michael Schroeder a écrit :
On Mon, Apr 25, 2011 at 03:41:23PM +0200, Cristian Morales Vega wrote:
* "EXPERIMENTAL support for package "collections" which are sort of like named triggers that only run once within a transaction. This can be used for example to avoid redundant calls for cache updates etc. (XXX add link to documentation once it exists)"
Experimental? Should we use this instead of multiple calls to gtk-update-icon-cache? It's expected that openSUSE 12.1 will use a newer RPM where collections are no longer experimental?
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
The issue is not that gtk-update-icon-cache is slow (well, I guess it's potentially an issue to some). The issue is that it has to be called after a package installs icons. And many packages don't do that, as it's easy to forget. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Apr 26, 2011 at 11:54:34AM +0200, Vincent Untz wrote:
The issue is not that gtk-update-icon-cache is slow (well, I guess it's potentially an issue to some). The issue is that it has to be called after a package installs icons. And many packages don't do that, as it's easy to forget.
Oh, in that case using the collection mechanism is fine. The only problem is, of course, that the packages won't work with older distribution versions. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2011/4/26 Michael Schroeder
On Tue, Apr 26, 2011 at 11:54:34AM +0200, Vincent Untz wrote:
The issue is not that gtk-update-icon-cache is slow (well, I guess it's potentially an issue to some). The issue is that it has to be called after a package installs icons. And many packages don't do that, as it's easy to forget.
Oh, in that case using the collection mechanism is fine. The only problem is, of course, that the packages won't work with older distribution versions.
The spec files would still need to add a "Collections: icon" line, wouldn't? It's still a line more than with file triggers (https://features.opensuse.org/305472), but since I don't expect them to be implemented anytime soon in RPM4* (and I suppose taking the Mandriva/RPM5 patch is out of the question) it seems like the less bad solution. Anyway if file triggers are ever implemented that specific collection could be easily disabled globally. But IMHO the cause today many packages don't call gtk-update-icon-cache is not that packagers forget. The cause to me seems to be that nobody is happy with any of the solutions... If we don't call gtk-update-icon-cache Gnome people complains, if we call it somebody else complains (installer people: https://bugzilla.novell.com/show_bug.cgi?id=395056). Until it's totally clear that tomorrow we will not change the policy, packagers will not want to do the work. * Even if here http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/ it says in 2009 Panu was working on it. What happened? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dne 26.4.2011 11:46, Michael Schroeder napsal(a):
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
So when installing such packages using zypper or YaST the collections would not help as libzypp installs packages one by one (just a single package in every RPM transaction). -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 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
2011/4/26 Ladislav Slezak
Dne 26.4.2011 11:46, Michael Schroeder napsal(a):
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
So when installing such packages using zypper or YaST the collections would not help as libzypp installs packages one by one (just a single package in every RPM transaction).
So another argument to change the default for commit.downloadMode from DownloadAsNeeded to DownloadInHeaps? ;-) IIRC the only argument for maintaining DownloadAsNeeded was hard drive space considerations. Otherwise the only way to get the wanted behavior would be at ZYpp level. Last time I looked at it "update-scripts" were an ugly solution for this, I'm not even sure if it was possible to use it for this purpose at all. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Apr 26, 2011 at 10:13:48PM +0200, Cristian Morales Vega wrote:
2011/4/26 Ladislav Slezak
: Dne 26.4.2011 11:46, Michael Schroeder napsal(a):
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
So when installing such packages using zypper or YaST the collections would not help as libzypp installs packages one by one (just a single package in every RPM transaction).
So another argument to change the default for commit.downloadMode from DownloadAsNeeded to DownloadInHeaps? ;-)
Actually the default has already changed, I think.
IIRC the only argument for maintaining DownloadAsNeeded was hard drive space considerations.
Otherwise the only way to get the wanted behavior would be at ZYpp level. Last time I looked at it "update-scripts" were an ugly solution for this, I'm not even sure if it was possible to use it for this purpose at all.
Zypp still calls 'rpm' for each transaction step for various reasons. One of them is that you can continue with the transaction if a step fails. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 27 Apr 2011, Michael Schroeder wrote:
On Tue, Apr 26, 2011 at 10:13:48PM +0200, Cristian Morales Vega wrote:
2011/4/26 Ladislav Slezak
: Dne 26.4.2011 11:46, Michael Schroeder napsal(a):
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
So when installing such packages using zypper or YaST the collections would not help as libzypp installs packages one by one (just a single package in every RPM transaction).
So another argument to change the default for commit.downloadMode from DownloadAsNeeded to DownloadInHeaps? ;-)
Actually the default has already changed, I think.
IIRC the only argument for maintaining DownloadAsNeeded was hard drive space considerations.
Otherwise the only way to get the wanted behavior would be at ZYpp level. Last time I looked at it "update-scripts" were an ugly solution for this, I'm not even sure if it was possible to use it for this purpose at all.
Zypp still calls 'rpm' for each transaction step for various reasons. One of them is that you can continue with the transaction if a step fails.
Which is a bug rather than a feature ;)
Richard.
--
Richard Guenther
2011/4/27 Richard Guenther
On Wed, 27 Apr 2011, Michael Schroeder wrote:
On Tue, Apr 26, 2011 at 10:13:48PM +0200, Cristian Morales Vega wrote:
2011/4/26 Ladislav Slezak
: Dne 26.4.2011 11:46, Michael Schroeder napsal(a):
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
So when installing such packages using zypper or YaST the collections would not help as libzypp installs packages one by one (just a single package in every RPM transaction).
So another argument to change the default for commit.downloadMode from DownloadAsNeeded to DownloadInHeaps? ;-)
Actually the default has already changed, I think.
IIRC the only argument for maintaining DownloadAsNeeded was hard drive space considerations.
Otherwise the only way to get the wanted behavior would be at ZYpp level. Last time I looked at it "update-scripts" were an ugly solution for this, I'm not even sure if it was possible to use it for this purpose at all.
Zypp still calls 'rpm' for each transaction step for various reasons. One of them is that you can continue with the transaction if a step fails.
Which is a bug rather than a feature ;)
I'm far from an RPM expert. But indeed, if "continue with as much packages as you can" is the wanted behavior when a package fails... probably that should be the behavior at RPM level? Having a behavior at RPM level and then change it at ZYpp level seems weird. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 27 Apr 2011, Cristian Morales Vega wrote:
2011/4/27 Richard Guenther
: On Wed, 27 Apr 2011, Michael Schroeder wrote:
On Tue, Apr 26, 2011 at 10:13:48PM +0200, Cristian Morales Vega wrote:
2011/4/26 Ladislav Slezak
: Dne 26.4.2011 11:46, Michael Schroeder napsal(a):
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
So when installing such packages using zypper or YaST the collections would not help as libzypp installs packages one by one (just a single package in every RPM transaction).
So another argument to change the default for commit.downloadMode from DownloadAsNeeded to DownloadInHeaps? ;-)
Actually the default has already changed, I think.
IIRC the only argument for maintaining DownloadAsNeeded was hard drive space considerations.
Otherwise the only way to get the wanted behavior would be at ZYpp level. Last time I looked at it "update-scripts" were an ugly solution for this, I'm not even sure if it was possible to use it for this purpose at all.
Zypp still calls 'rpm' for each transaction step for various reasons. One of them is that you can continue with the transaction if a step fails.
Which is a bug rather than a feature ;)
I'm far from an RPM expert. But indeed, if "continue with as much packages as you can" is the wanted behavior when a package fails... probably that should be the behavior at RPM level? Having a behavior at RPM level and then change it at ZYpp level seems weird.
Btw, the usual answer I got was not the above but that if an rpm
transaction fails there is no way to roll it back. That's true,
but of course the same is true for a failed single-rpm transaction.
I suppose the real issue is that zypp doesn't know how to build
a set of rpms that form (minimal) completable transactions, and
feeding all rpms of a "zypp transaction" to rpm may cause
memory usage issues (another answer I got) or in case of a
transaction failure a system status that is harder to repair
manually.
Of course we know that you can get a broken system trivially
by doing partial transactions that render rpm itself useless
(like updating liblzma ...). Something rpm easily avoids ...
Thus, the answer in the end is: "never change a (working) system"
(with bugs you all know).
Richard.
--
Richard Guenther
Dne 27.4.2011 12:03, Michael Schroeder napsal(a):
So another argument to change the default for commit.downloadMode from DownloadAsNeeded to DownloadInHeaps? ;-)
Actually the default has already changed, I think.
The default is currently "DownloadInAdvance" (but during the initial installation via YaST it's "DownloadAsNeeded") -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 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
participants (5)
-
Cristian Morales Vega
-
Ladislav Slezak
-
Michael Schroeder
-
Richard Guenther
-
Vincent Untz