[pacman-dev] vercmp wildcards?
Just checking the sanity of an idea here: What do you all think of supporting wildcards for version comparisons? I was thinking fnmatch could almost be dropped in directly to alpm_pkg_vercmp in place of the initial strcmp. Use case: readline version 6.0.003 bash depends readline=6.0.* Thoughts?
On Mon, Jul 20, 2009 at 5:18 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
Just checking the sanity of an idea here:
What do you all think of supporting wildcards for version comparisons? I was thinking fnmatch could almost be dropped in directly to alpm_pkg_vercmp in place of the initial strcmp.
Use case: readline version 6.0.003 bash depends readline=6.0.*
Thoughts?
Initial thoughts are this doesn't seem like the greatest idea. However, it has its fair use cases, and I can't really justify my distaste toward it. I feel like there are a lot of tricky situations with version numbers. Without commenting on the practicality too much, know that you can fairly easily fool around with vercmp and its implementation run it through its test suite, which runs on either "make check" or can be invoked directly by running ./pactest/vercmptest.sh ./src/util/vercmp. -Dan
Just checking the sanity of an idea here:
What do you all think of supporting wildcards for version comparisons? I was thinking fnmatch could almost be dropped in directly to alpm_pkg_vercmp in place of the initial strcmp.
Use case: readline version 6.0.003 bash depends readline=6.0.*
Thoughts?
All distros (and package managers) I know doesn't use version wildcards. This is not an argument, I just remark this. In fact, I don't see why that would be problematic. That can be more "comfortable" in many cases, see kernel>=2.6.29 & kernel<2.6.30 dependencies. These "double" dependencies should be used with most of the packages (libjpeg.so.7 and so on), and wildcards would be easier here. Staying with kernel example, there it would not help too much (regexp or something more sophisticated stuff is needed here): If you require 2.6.29.*, then you exclude 2.6.29; if you require 2.6.29*, then you also include 2.6.295 (this is not real life example, but with kernel 2.6.2 it is). Conclusion: I don't know. The packagers should be careful, not the package manager. ;-) Bye
On Tue, Jul 21, 2009 at 15:11, Nagy Gabor<ngaba@bibl.u-szeged.hu> wrote:
Just checking the sanity of an idea here:
What do you all think of supporting wildcards for version comparisons? I was thinking fnmatch could almost be dropped in directly to alpm_pkg_vercmp in place of the initial strcmp.
Use case: readline version 6.0.003 bash depends readline=6.0.*
Thoughts?
All distros (and package managers) I know doesn't use version wildcards. This is not an argument, I just remark this.
well, it's not necessary to use '.*' - it can be coded in a way that 1.2 includes 1.2.3 but not 1.23 (I'm not suggesting that it is better, just pointing an option).
In fact, I don't see why that would be problematic. That can be more "comfortable" in many cases, see kernel>=2.6.29 & kernel<2.6.30 dependencies. These "double" dependencies should be used with most of the packages (libjpeg.so.7 and so on), and wildcards would be easier here.
The difference is that with kernel it is known fact that all modules require rebuilding with every major version change, but you cannot safely assume that libjpeg ABI won't be broken with a minor version (e.g. 7.0 -> 7.1). -- Roman Kyrylych (Роман Кирилич)
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Nagy Gabor
-
Roman Kyrylych