[opensuse-packaging] 13-check-invalid-provides trips over '+' in package name due to grep -E
Hi Dirk, this single test actively hinders to correctly release an important package (for me): hylafax+. Yup, one could argue, that using + in project names is somewhat silly, but it's exactly, what is needed here. HylaFAX is effectively forked by HylaFAX+. Now, the situation is unfortunate: hylafax is released with major version 4 and 6, while hylafax+ is released as 5. Keeping the name hylafax will replace the + version with the 6th version on certain occasions, and those, who follow both developments will agree, that this is the least desired. Either use one or the other but don't replace them vice versa, please. You will find my packages here: https://build.opensuse.org/project/show?project=home%3Afrispete%3Ahylafax What I would like to do is letting my hylafax+ package: Provides: hylafax fax_daemon Conflicts: hylafax sendfax Obsoletes: hylafax and all is well, up to 13-check-invalid-provides: the test boils down to: $ echo hylafax | grep -E "^hylafax+[[:space:]]*$" hylafax $ while this is desired here: $ echo hylafax | grep -G "^hylafax+[[:space:]]*$" $ Using basic regex provide exactly the means of the unversioned package name check, while not tripping over the '+'. According to the man page, only ?, +, {, |, (, and ) lose their special meaning, thus: $ echo hylafax+ | grep -G "^hylafax+[[:space:]]*$" hylafax+ $ the + is matched literally, which is desired. I agree, this case is pathologic, but I can't imagine any ill side effects on this change, do you? It's a real pity to not being able to tag this package correctly, e.g. allowing for a clean package replacement. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 2010-02-25 21:41, Hans-Peter Jansen wrote:
and all is well, up to 13-check-invalid-provides: the test boils down to:
$ echo hylafax | grep -E "^hylafax+[[:space:]]*$" hylafax $
while this is desired here:
$ echo hylafax | grep -G "^hylafax+[[:space:]]*$" $
Using basic regex provide exactly the means of the unversioned package name check, while not tripping over the '+'. According to the man page, only ?, +, {, |, (, and ) lose their special meaning, thus:
$ echo hylafax+ | grep -G "^hylafax+[[:space:]]*$" hylafax+ $
the + is matched literally, which is desired.
echo "$input" | pcregrep '^\Q'"$pkgnamehere"'\E\s*$' Would fix it once and for all without having to resort to awkward preescaping of pluses and so. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 25 February 2010, 21:48:23 Jan Engelhardt wrote:
On Thursday 2010-02-25 21:41, Hans-Peter Jansen wrote:
and all is well, up to 13-check-invalid-provides: the test boils down to:
$ echo hylafax | grep -E "^hylafax+[[:space:]]*$" hylafax $
while this is desired here:
$ echo hylafax | grep -G "^hylafax+[[:space:]]*$" $
Using basic regex provide exactly the means of the unversioned package name check, while not tripping over the '+'. According to the man page, only ?, +, {, |, (, and ) lose their special meaning, thus:
$ echo hylafax+ | grep -G "^hylafax+[[:space:]]*$" hylafax+ $
the + is matched literally, which is desired.
echo "$input" | pcregrep '^\Q'"$pkgnamehere"'\E\s*$'
Would fix it once and for all without having to resort to awkward preescaping of pluses and so.
While I'm a big fan of your work (and already snatched some cool tricks from some of your specs ;-)), I think, that 's/-E/-G/' is going to effectively fix the issue in question _without_ any real downsides. The remaining special characters are obscure enough for package names to be ignored: [], ^, $, \ and *. Wait, while at it, is '.' allowed as such? There's no need to quote or preescape anything here: by turning the regex syntax from extended to basic, the fix is done. Quote from man 1+ grep: Basic vs Extended Regular Expressions In basic regular expressions the meta-characters ?, +, {, |, (, and ) lose their special meaning; instead use the backslashed versions \?, \+, \{, \|, \(, and \). Since these aren't needed nor desired to have this special meaning here at all. It's that simple. Some issues with your suggestion from my side: - another package dependency in the mandatory build environment - I haven't heard from pcregrep until you mentioned it (okay, my fault) - I failed to parse that expression on the first sight (okay, my fault again, \Q and \E will stop/start the special meaning of special characters, I guess...) Judge, we will have to subtract the last two, which keeps the first only... Seriously, sanity check of packaging is a major point, and that should be done as comprehensible as possible. Thanks, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 2010-02-25 23:45, Hans-Peter Jansen wrote:
echo "$input" | pcregrep '^\Q'"$pkgnamehere"'\E\s*$'
Some issues with your suggestion from my side: - another package dependency in the mandatory build environment
Oh you can use perl instead. That's already installed anyway. | perl -e 'print if m{^\Q'"$pkgnamehere"'\E\s*$}' Or even grep, which is even more likely to be installed. | grep -P '^\Q'"$pkgnamehere"'\E\s*$' though -P is SUSE-specific and I've learnt to use pcregrep instead because that works cross-distro.
- I haven't heard from pcregrep until you mentioned it (okay, my fault) - I failed to parse that expression on the first sight (okay, my fault again, \Q and \E will stop/start the special meaning of special characters, I guess...)
Judge, we will have to subtract the last two, which keeps the first only...
Seriously, sanity check of packaging is a major point, and that should be done as comprehensible as possible.
Thanks,
While I'm a big fan of your work (and already snatched some cool tricks from some of your specs ;-))
Since it's all standard to me, which specific tricks are you referring to? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 25 February 2010, 23:53:24 Jan Engelhardt wrote:
Since it's all standard to me, which specific tricks are you referring to?
Well, I've learned quite a bit from your nvidia driver package, and some other things, I've forgotten by now. Usually, I do remember them, when looking for a fix. But since I greased your beard with so much honey: what I dislike is, that you have too many packages in your repos. For a distribution, that's fine, but if you only look for some special packages, it's awful to pull a lot of other stuff. That depresses the popularity of your repos considerably in my eyes. Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday 2010-02-26 00:52, Hans-Peter Jansen wrote:
But since I greased your beard with so much honey: what I dislike is, that you have too many packages in your repos.
Well hey I've got so many systems to administer and use, I need all of it. And the only sane choice is to have everything in a single repo. It's just infeasible to add tons of .repo files to every system *and* keep them up to date (well yeah turns out you can use $releasever or some magic string in SUSE too, but that's a recent discovery). gcc-4.5 for example used to be in home:rguenther, then it moved to devel:gcc. On the other hand, all packages that accumulated in my repo are just a sign of openSUSE lacking them. Of course I have been busy in SR'ing pieces, but then there are sometimes nitpicky situations (kernel-source; solvable) or unreasonably conservative/inertial gatekeepers (net-tools; BNC#492665, FATE#307200). In a way, you could say that the amount of RPMs in my repo is a (combined) factor of and index about: 1. interesting stuff, new stuff 2. stuff that openSUSE can't include due to legalalala 3. different stuff (customization like shell prompts - something that is unlikely to ever make it upstream) 4. discontent with openSUSE Maybe I should split my SRPM directory up into subdirectories based upon these categories to keep an easy count. Watch out for when directory number 4 grows.
For a distribution, that's fine, but if you only look for some special packages, it's awful to pull a lot of other stuff. That depresses the popularity of your repos considerably in my eyes.
Well let me put in this disclaimer: - If User does not like it, don't use it - User is not required to download more than what the dependencies require - User is not required to install more than what the dependencies require - Dependencies are built in good faith, especially you won't get the much-needed net-tools fix forced into the system (unless you explicitly request to have a jeng-approved system by installing jeng-*-packages). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Feb 25, 2010 at 09:41:56PM +0100, Hans-Peter Jansen wrote:
What I would like to do is letting my hylafax+ package:
Provides: hylafax fax_daemon Conflicts: hylafax sendfax Obsoletes: hylafax
Btw, that's a self-conflicts. A Package must not conflict with something it provides. "Obsoletes: hylafax" is enough. 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-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday 26 February 2010, 11:30:27 Michael Schroeder wrote:
On Thu, Feb 25, 2010 at 09:41:56PM +0100, Hans-Peter Jansen wrote:
What I would like to do is letting my hylafax+ package:
Provides: hylafax fax_daemon Conflicts: hylafax sendfax Obsoletes: hylafax
Btw, that's a self-conflicts. A Package must not conflict with something it provides. "Obsoletes: hylafax" is enough.
Ah, sure. Stupid me. Thanks for the catch (and the note). Fixed. If only I could do the correct Provides:. From what I have now: Name: hylafax+ Provides: fax_daemon Conflicts: sendfax Obsoletes: hylafax %package -n %{name}-client Provides: fax_client Conflicts: sendfax Obsoletes: hylafax-client BS complains: hylafax+.i586: W: obsolete-not-provided hylafax hylafax+-client.i586: W: obsolete-not-provided hylafax-client If a package is obsoleted by a compatible replacement, the obsoleted package must also be provided in order to provide clean upgrade paths and not cause unnecessary dependency breakage. If the obsoleting package is not a compatible replacement for the old one, leave out the provides. Dirk? Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 25 February 2010, Hans-Peter Jansen wrote:
this single test actively hinders to correctly release an important package (for me): hylafax+. Yup, one could argue, that using + in project names is somewhat silly, but it's exactly, what is needed here. HylaFAX is effectively forked by HylaFAX+. Now, the situation is unfortunate: hylafax is released with major version 4 and 6, while hylafax+ is released as 5. Keeping the name hylafax will replace the + version with the 6th version on certain occasions, and those, who follow both developments will agree, that this is the least desired. Either use one or the other but don't replace them vice versa, please.
Thanks for your notification, I've planned to put this check into rpmlint anyway, where this problem won't occur. I'll fix this for openSUSE Factory, is that good enough? Greetings, Dirk -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi Dirk, On Tuesday 02 March 2010, 11:18:39 Dirk Müller wrote:
On Thursday 25 February 2010, Hans-Peter Jansen wrote:
this single test actively hinders to correctly release an important package (for me): hylafax+. Yup, one could argue, that using + in project names is somewhat silly, but it's exactly, what is needed here. HylaFAX is effectively forked by HylaFAX+. Now, the situation is unfortunate: hylafax is released with major version 4 and 6, while hylafax+ is released as 5. Keeping the name hylafax will replace the + version with the 6th version on certain occasions, and those, who follow both developments will agree, that this is the least desired. Either use one or the other but don't replace them vice versa, please.
Thanks for your notification, I've planned to put this check into rpmlint anyway, where this problem won't occur. I'll fix this for openSUSE Factory, is that good enough?
If this means, that I'm not able to stick the correct Provides: tag into my package, that would make me rather unhappy.. Would it take a big effort to apply a fix similar to the attached one to post-build-checks in order to get my package in shape correctly for 11.1 and probably 11.2 really soon now? May I branch/fix/sr post-build-checks in order to reduce your effort to the bare minimum? Cheers, Pete
On Tuesday 02 March 2010, Hans-Peter Jansen wrote:
Thanks for your notification, I've planned to put this check into rpmlint anyway, where this problem won't occur. I'll fix this for openSUSE Factory, is that good enough? If this means, that I'm not able to stick the correct Provides: tag into my package, that would make me rather unhappy..
no, it just means that the check in post-build-checks is going away and moving into rpmlint, where it can be suppressed via normal means (rpmlintrc etc).
Would it take a big effort to apply a fix similar to the attached one to post-build-checks in order to get my package in shape correctly for 11.1 and probably 11.2 really soon now?
those are already released, we'd have to release maintenance updates for that..
May I branch/fix/sr post-build-checks in order to reduce your effort to the bare minimum?
for factory, that would be a valid quick fix, yes, but I rather fix it once and for all.. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 02 March 2010, 20:06:20 Dirk Müller wrote:
On Tuesday 02 March 2010, Hans-Peter Jansen wrote:
Thanks for your notification, I've planned to put this check into rpmlint anyway, where this problem won't occur. I'll fix this for openSUSE Factory, is that good enough?
If this means, that I'm not able to stick the correct Provides: tag into my package, that would make me rather unhappy..
no, it just means that the check in post-build-checks is going away and moving into rpmlint, where it can be suppressed via normal means (rpmlintrc etc).
May I branch/fix/sr post-build-checks in order to reduce your effort to the bare minimum?
for factory, that would be a valid quick fix, yes, but I rather fix it once and for all..
Dirk, I fixed this issue with a package link to post-build-checks from openSUSE:Factory in my project with the fix in place. If only I would have been touched earlier with the clue stick, I wouldn't have made so much churn.. Sorry about that. Last question: if you remove post-build-checks from factory one day, does my local package survive, or is it dangling/dysfunctional somehow then? (There had been changes to package link semantics, I doesn't fully grok, yet..) Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 02 March 2010, Hans-Peter Jansen wrote:
Sorry about that.
indeed, that is a good workaround!
Last question: if you remove post-build-checks from factory one day, does my local package survive, or is it dangling/dysfunctional somehow then? (There had been changes to package link semantics, I doesn't fully grok, yet..)
I'm not going to remove the package, I'm only going to remove (actually move the check to rpmlint) this particular check from the package. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (4)
-
Dirk Müller -
Hans-Peter Jansen -
Jan Engelhardt -
Michael Schroeder