Re: Cleaning out some local patches of mine..
On Dec 5, 2008, at 2:47 AM, Per Øyvind Karlsen wrote: 2008/12/5 Per Øyvind Karlsen <[EMAIL PROTECTED]> Oh, and I also got this one: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&view=log Any suggestions on what would be the best approach? Just use #ifdef vendor? It seems to me that this might be useful also for others that are performing the same task with the possibility of very high load.. I forgot, FYI: # important patch fixing parse_hdlist (and so genhdlist2) on heavy loaded boxes # (without this patch it timeouts after a read miss of 1 second (even a pipe), # and there is no way we can retry since we would need to backtrack the fd) Depends on what problem needs to be solved. There needs to be a watchdog on network connecting waiting for a response that isn't going to occur needs to be terminated. But one timeout value for all usage cases can never be chosen successfully. And there hasn't been a whole lot of thought into choosing the values. Is 60 seconds enough? FYI, its not impossibly hard to retrieve sufficient state from a FD_t to attempt a retry. Not that retries solve any issue in general -- only in computer science is retrying exactly the same operation expected to correct an error; most errors are systemic, not transient, and so a retry just delays the inevitable failure. 73 de Jeff smime.p7s Description: S/MIME cryptographic signature
Re: Cleaning out some local patches of mine..
2008/12/5 Per Øyvind Karlsen <[EMAIL PROTECTED]> > Oh, and I also got this one: > > http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&view=log > > Any suggestions on what would be the best approach? > Just use #ifdef vendor? It seems to me that this might be useful also for > others that are performing the same task with the possibility of very high > load.. I forgot, FYI: # important patch fixing parse_hdlist (and so genhdlist2) on heavy loaded boxes # (without this patch it timeouts after a read miss of 1 second (even a pipe), # and there is no way we can retry since we would need to backtrack the fd) -- Regards, Per Øyvind
Re: Cleaning out some local patches of mine..
2008/12/5 Per Øyvind Karlsen <[EMAIL PROTECTED]> > While I've commited most of the mandriva patches upstream, I still got a > few > ones left that I've been uncertain about and hasn't bothered with looking > at yet: > > > http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.1-fileconflicts.patch?root=rpm5distro&view=log > (https://bugzilla.redhat.com/show_bug.cgi?id=151609) > > > http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.4-rpmqv-ghost.patch?root=rpm5distro&view=log > (https://qa.mandriva.com/show_bug.cgi?id=19392) > > Reading bugzilla entries, both suggests that these issues has been fixed > upstream already, is this the case? Is there no longer any sense to these > patches? > > I'd like to get rid of these, then I'd be down to only three local patches > left. :o) > > (Feel free to comment on the other ones while you're at it;) > -- > Regards, > Per Øyvind Here I got one that I'm not sure if I understand: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-build-expand-field-for-single-token.patch?root=rpm5distro&view=log The comment I find in spec about it is the following: # rpm now check there is only one token per field # too bad, the check is performed before macro expansion... Oh, and I also got this one: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&view=log Any suggestions on what would be the best approach? Just use #ifdef vendor? It seems to me that this might be useful also for others that are performing the same task with the possibility of very high load.. I dunno, but it's the last local patch left, would be nice to get rid of it to satisfy my neatfreak urges. ;) -- Regards, Per Øyvind
Re: Cleaning out some local patches of mine..
2008/12/5 Jeff Johnson <[EMAIL PROTECTED] > > If you want both a --ghost enabler as well as a --noghost disabler, go for > it. > > However, what works best for rpm (in my experience) is enabled > functionality > with a disabler. Opt-in behavior for new functionality takes many more > years to be used, might as well have not done the implementation at all. > > However, if both enabler/disabler options have to be added everywhere, its > gonna be a bit of a mess, and likely will require automation through > popt for bit field set/clr (which likely needs doing somewhen for other > reasons). > > But as long as the options are not displayed in --help or documented in > rpm.8 > noone will really care. > Ah, I see, I did of course not do any research on this myself before asking.. :p But I feel a bit confused, rpm checks ghost files by default (which is also what this patch activates with --ghost), while --noghost will disable checking? If so, I don't see much sense in the patch and will gladly drop it without giving it any second thoughts. :) > > Reading bugzilla entries, both suggests that these issues has been fixed > upstream already, is this the case? Is there no longer any sense to these > patches? > > > The disagreement over what the default value for file conflicts > has been going on since RHEL4. Nothing has changed. Some > want full stop failure exit, others are okay with "best effort" > continuing. And there is only one default behavior choice possible. > I see, I guess Mandriva has a different take on policies for these things in general, using different package names for situations with several versions of a package and splitting out library packages etc. for different archs to accomplish multilib rather than relying on coloring or large blobs.. Seems to be a clear "cultural" difference between distributions and policies, putting it under #ifdef vendor. :) -- Regards, Per Øyvind
Re: Cleaning out some local patches of mine..
On Dec 5, 2008, at 12:40 AM, Per Øyvind Karlsen wrote: While I've commited most of the mandriva patches upstream, I still got a few ones left that I've been uncertain about and hasn't bothered with looking at yet: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.1-fileconflicts.patch?root=rpm5distro&view=log (https://bugzilla.redhat.com/show_bug.cgi?id=151609) The default value for these will be to resolve conflicts as last in. Put the patch under a vendor #ifdef if you wish. http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.4-rpmqv-ghost.patch?root=rpm5distro&view=log (https://qa.mandriva.com/show_bug.cgi?id=19392) If you want both a --ghost enabler as well as a --noghost disabler, go for it. However, what works best for rpm (in my experience) is enabled functionality with a disabler. Opt-in behavior for new functionality takes many more years to be used, might as well have not done the implementation at all. However, if both enabler/disabler options have to be added everywhere, its gonna be a bit of a mess, and likely will require automation through popt for bit field set/clr (which likely needs doing somewhen for other reasons). But as long as the options are not displayed in --help or documented in rpm.8 noone will really care. Reading bugzilla entries, both suggests that these issues has been fixed upstream already, is this the case? Is there no longer any sense to these patches? The disagreement over what the default value for file conflicts has been going on since RHEL4. Nothing has changed. Some want full stop failure exit, others are okay with "best effort" continuing. And there is only one default behavior choice possible. I've not seen the --ghost enabler patch before now. 73 de Jeff smime.p7s Description: S/MIME cryptographic signature
