Re: Fix rpm -qa \*foo\*
On Sep 12, 2013, at 11:52 PM, Per Øyvind Karlsen wrote: 2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:51 PM, Per Øyvind Karlsen wrote: 2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. We actually discussed this one quite a while a ago, where you acknowledged it yourself (the regression were introduced here: http://rpm5.org/cvs/chngview?cn=16299 ) Everyone's opinions -- including mine -- change with experience. Expecting me to remember and be consistent with a patch from 2y ago that you claim is/was related to rpm -qa \*foo\* regression from a wildcard behavior that has never been specified, only de facto, when there are other non-feature related behaviors that are often in need of fixing is unwise. The issue that needs consensus is whether rpm -qa \*foo\* is useful, particularly when there are other designed/planned/implemented implicit switches to permit rpm -qa ^.*foo.* i.e. your trivial reproducer is already a malformed *RE pattern, rather a sloppy/foolish DWIM naive fuzz-busting query. There already is a means Other and more efficient means are rather irrelevant in this context... The undeniable fact is that the existing and expected behaviour changed in changeset #16299 due to what seems like an apparent coding mistake, breaking usage of 'rpm -qa \*foo\*' as is used by many (whether it being inefficient, better ways exists or not etc. is really besides the point as educating end users about habits goes beyond the scope of the discussion and bug fix here), making it hard to dismiss as not being a regression that should be fixed.. Luser will only notice what's expected and used to work, no longer working, blissfully ignorant and careless about what you debate and reject this patch based on.. RPM has never supported patterns in queries generally. Any argument of expected/existi9ng can be dealt with by using existing versions of RPM that support whatever syntax you are expecting. Any further discussion of what SHOULD be done needs to be discussed at launchpad. Or patch however you wish. 73 de Jeff -- Regards, Per Øyvind
Re: Fix rpm -qa \*foo\*
2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:51 PM, Per Øyvind Karlsen wrote: 2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. We actually discussed this one quite a while a ago, where you acknowledged it yourself (the regression were introduced here: http://rpm5.org/cvs/chngview?cn=16299 ) Everyone's opinions -- including mine -- change with experience. Expecting me to remember and be consistent with a patch from 2y ago that you claim is/was related to rpm -qa \*foo\* regression from a wildcard behavior that has never been specified, only de facto, when there are other non-feature related behaviors that are often in need of fixing is unwise. The issue that needs consensus is whether rpm -qa \*foo\* is useful, particularly when there are other designed/planned/implemented implicit switches to permit rpm -qa ^.*foo.* i.e. your trivial reproducer is already a malformed *RE pattern, rather a sloppy/foolish DWIM naive fuzz-busting query. There already is a means Other and more efficient means are rather irrelevant in this context... The undeniable fact is that the existing and expected behaviour changed in changeset #16299 due to what seems like an apparent coding mistake, breaking usage of 'rpm -qa \*foo\*' as is used by many (whether it being inefficient, better ways exists or not etc. is really besides the point as educating end users about habits goes beyond the scope of the discussion and bug fix here), making it hard to dismiss as not being a regression that should be fixed.. Luser will only notice what's expected and used to work, no longer working, blissfully ignorant and careless about what you debate and reject this patch based on.. -- Regards, Per Øyvind
Fix rpm -qa \*foo\*
The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. -- Regards, Per Øyvind rpm-5.4.9-fix-rpm_qa-pattern.patch Description: Binary data
Re: Fix rpm -qa \*foo\*
On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. I personally have no interest in enabling foolish/sloppy queries on a random feature walk through patch streams of unknown viability, and poorly understood consequences, @rpm5.org, particularly when I am obligated to do the maintenance work to respond to future flaws and objections of other people's efforts. Last I heard you were too discouraged to undertake the reasonably sane effort(s) that are needed ... YMMV. Short answer (which I have said many times already): A blueprint at http://launchpad.net/rpm is the starting point for new feature deployment. 73 de Jeff__ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fix rpm -qa \*foo\*
2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. We actually discussed this one quite a while a ago, where you acknowledged it yourself (the regression were introduced here: http://rpm5.org/cvs/chngview?cn=16299 ) I've provided you with a trivial reproducer, but considering the large amount of patches I have in queue, I don't really have the time nor that much incentive for starting on writing accompanying regression tests, especially not when I'm not overly existed about how the current regression tests are implemented/maintained, nor is my motivation for writing regression tests for (yet a bunch of) bug fix patches I maintain locally for a package. If commit access were restored, doing more of that kind maintenance work again would be of greater interest, but when not, I'm not very eager to take on responsibilities with the resulting tediousness.. I personally have no interest in enabling foolish/sloppy queries on a random feature walk through patch streams of unknown viability, and poorly understood consequences, @ rpm5.org, particularly when I am obligated to do the maintenance work to respond to future flaws and objections of other people's efforts. Last I heard you were too discouraged to undertake the reasonably sane effort(s) that are needed ... YMMV. And I'm now trying to, am I not? :) Seriously speaking, a lot of things came up and in the way for things, but I will at least sporadically be trying to push all ~fixes for now, then get back to ~features etc. with blueprints provided and code cleaned up whenever I find the time. :) Short answer (which I have said many times already): A blueprint at http://launchpad.net/rpm is the starting point for new feature deployment. This isn't a feature, but rather a bug fix. -- Regards, Per Øyvind
Re: Fix rpm -qa \*foo\*
On Aug 26, 2013, at 2:51 PM, Per Øyvind Karlsen wrote: 2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. We actually discussed this one quite a while a ago, where you acknowledged it yourself (the regression were introduced here: http://rpm5.org/cvs/chngview?cn=16299 ) Everyone's opinions -- including mine -- change with experience. Expecting me to remember and be consistent with a patch from 2y ago that you claim is/was related to rpm -qa \*foo\* regression from a wildcard behavior that has never been specified, only de facto, when there are other non-feature related behaviors that are often in need of fixing is unwise. The issue that needs consensus is whether rpm -qa \*foo\* is useful, particularly when there are other designed/planned/implemented implicit switches to permit rpm -qa ^.*foo.* i.e. your trivial reproducer is already a malformed *RE pattern, rather a sloppy/foolish DWIM naive fuzz-busting query. There already is a means I've provided you with a trivial reproducer, but considering the large amount of patches I have in queue, I don't really have the time nor that much incentive for starting on writing accompanying regression tests, especially not when I'm not overly existed about how the current regression tests are implemented/maintained, nor is my motivation for writing regression tests for (yet a bunch of) bug fix patches I maintain locally for a package. If commit access were restored, doing more of that kind maintenance work again would be of greater interest, but when not, I'm not very eager to take on responsibilities with the resulting tediousness.. I personally have no interest in enabling foolish/sloppy queries on a random feature walk through patch streams of unknown viability, and poorly understood consequences, @rpm5.org, particularly when I am obligated to do the maintenance work to respond to future flaws and objections of other people's efforts. Last I heard you were too discouraged to undertake the reasonably sane effort(s) that are needed ... YMMV. And I'm now trying to, am I not? :) At the time I replied, there was only a single patch in my mbox. I am proceeding through your e-mails as rapidly as I can. Seriously speaking, a lot of things came up and in the way for things, but I will at least sporadically be trying to push all ~fixes for now, then get back to ~features etc. with blueprints provided and code cleaned up whenever I find the time. :) Short answer (which I have said many times already): A blueprint at http://launchpad.net/rpm is the starting point for new feature deployment. This isn't a feature, but rather a bug fix. We disagree on what is a bug and what is a feature here. Which is why I suggested an explicit blueprint rather than willy-nilly application of hacky patches. 73 de Jeff 73 de Jeff -- Regards, Per Øyvind
