Re: [Rpm-maint] RPM 4.9.0 alpha available
On Wed, 24 Nov 2010, Michael Schroeder wrote: On Mon, Nov 22, 2010 at 03:18:46PM +0200, Panu Matilainen wrote: On Fri, 19 Nov 2010, Michael Schroeder wrote: - tilde support in version comparison No fundamental objections, it'd simplify packaging of pre-release versions a great deal. The current suggested patch has some issues though, see http://rpm.org/ticket/56#comment:6 Yes, should I create a new patch? If you have time to look at the more than one tilde-case, then please do. As for the compatibility tracking and all that: looking at the options, it'd probably only create a much bigger mess than just slipping it in quietly. It's not as if meaning of '.' is getting redefined... - triggers on provides instead of package names I dread to think what would happen for the existing triggers when they start hitting compatibility provides (provides added on package renames / replacements). Me thinks it's best to leave the existing trigger semantics alone... Yes, that also worries me. We could define a provides() namespace to tell rpm to look at provides, but I'm not sure if it's worth it. (This provides() might also be used to make obsoletes work on provides instead of names, which might be useful in some rare cases.) I'd say lets see how the collections thing pans out. It's not going to be ready in 4.9.0 but once 4.9.x is branched I intend to get back to it and hopefully it can be backported to 4.9.x once deemed stable. The new collections feature behaves largely like named virtual triggers and as it's a new mechanism with an opt-in behavior, it's safe from compatibility point of view. It will be experimental-only in 4.9 initially though as various open questions and issues remain, at least some of them can be found in these threads: http://lists.rpm.org/pipermail/rpm-maint/2010-June/002766.html http://lists.rpm.org/pipermail/rpm-maint/2010-June/002787.html Comments/ideas would be welcome. Yes, I followed the threads but didn't look depply into the patches. - weak dependencies (basically just parsing them and storing them in the rpm header) Yup. It's something I keep kicking around every now and then and ending up not feeling happy enough to commit. The thing is, as soon as we have weak dependencies, rpm will need/want to deal with them to some extent - at least ordering should be aware of them Well, should is a bit too strong, it's more like nice to have. As rpm is free to ignore them it is no error to ignore them in the ordering process. Yeah.. but adding at least the soft requires into ordering is pretty trivial. Reverse (soft) dependencies might be more involved but shouldn't be much of a problem (although I haven't really looked into it) (and then there's the long-standing request of allowing ordering requests without declaring strict dependencies which is a sub-case of weak requires) One thing that bothers me with the existing patches is using another bit of the already scarce resource of rpmdsFlags bitfield for something that doesn't actually /do/ anything (the strong flag). I do realize changing that would be cumbersome for the existing users, but I'd rather put that data into a separate (integer array) tag and call it RPMTAG_SUGGESTSPRIORITY or such. Rpm itself should be fine with the knowledge whether a dependency can be ignored or not, ie the existing RPMSENSE_MISSINGOK. That's just some historic thing. At the time I did the SUSE patches, the SUGGESTS/ENHANCES tags were already reserved and I hijacked the old RPMSENSE_PATCHES flag used for patchrpms. Thus I didn't need to reserve new bits/tags. Nod. Wouldn't be the end of the world either, I'd just rather think of the slot RPMSENSE_PATCHES left as a free bit for something that absolutely /must/ be in the dsflags. It would be much cleaner to put the strong versions in new tags. Okay, if you can live with a transition phase where the strongness moves to a separate tag from being a dsflag then lets put the strongness/priority-thingie to a new tag. Mm.. or do you mean having new RPMTAG_RECOMMENDS* etc triplets for the strong versions? Thats of course one option too. I was thinking more of a new integer array tag that adds priority to each dependency, which could express more levels than just weak/strong hint. (and in theory, perhaps, could be used for hard requires too: eg if there's a dependency loop that needs cutting then prefer the higher priority dependency) All in all, from rpm POV, weak requires are /relatively/ clear. The enhances side of things is another story: they're a weak version of something we don't have at (and probably dont want to have): reverse requires. Which makes the whole thing conceptually quite a platypus in rpm's world. Of course rpm is free to ignore them completely but... I agree that reverse requires are strange and should not be supported The
Re: [Rpm-maint] RPM 4.9.0 alpha available
On Thu, 25 Nov 2010, Michael Schroeder wrote: On Thu, Nov 25, 2010 at 10:48:08AM +0200, Panu Matilainen wrote: If you have time to look at the more than one tilde-case, then please do. Okey, I'll send a patch later this day. Cool. As for the compatibility tracking and all that: looking at the options, it'd probably only create a much bigger mess than just slipping it in quietly. It's not as if meaning of '.' is getting redefined... Agreed. It would be much cleaner to put the strong versions in new tags. Okay, if you can live with a transition phase where the strongness moves to a separate tag from being a dsflag then lets put the strongness/priority-thingie to a new tag. Mm.. or do you mean having new RPMTAG_RECOMMENDS* etc triplets for the strong versions? Thats of course one option too. Yes, that's what I meant. Makes 'rpm -q --recommends' a lot easier, too. Yup, it'd make some things easier, other things .. well, not harder exactly, just more verbose perhaps (in code). I was thinking more of a new integer array tag that adds priority to each dependency, which could express more levels than just weak/strong hint. (and in theory, perhaps, could be used for hard requires too: eg if there's a dependency loop that needs cutting then prefer the higher priority dependency) The current suggests/recommends has a clear semantics (at least in the zypp stack): recommends are pre-selected, suggests are just listed. I think making this more complicated will confuse users even more. Yup, that's the obvious semantics for them. I didn't mean exposing 1- levels of choice for the users either, but more of an internal presentation of the data. But using entirely separate tags for the variants would have its advantages. Also I seem to recall a discussion/comments regarding reverse obsoletes, where a package could declare itself being obsoleted by something else (ObsoletedBy: foo). I thought it was in the problems pages in rpm.org wiki but can't seem to find it... Now that you mention it, I think one of our Czech developers suggested that feature on the mailing list. But I don't remember the use cases for that feature. With those tips I managed to find it: http://lists.rpm.org/pipermail/rpm-maint/2009-September/002495.html - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RPM 4.9.0 alpha available
On Thu, Nov 25, 2010 at 12:55:17PM +0200, Panu Matilainen wrote:
On Thu, 25 Nov 2010, Michael Schroeder wrote:
On Thu, Nov 25, 2010 at 10:48:08AM +0200, Panu Matilainen wrote:
If you have time to look at the more than one tilde-case, then please do.
Okey, I'll send a patch later this day.
Cool.
Patch attached. Seems to work well, but a couple of testcases
in rpmvercmp.at would be nice.
Oh, I just noticed that it changes the semantics a bit:
old:
rpm.vercmp(1., 1) - 1
rpm.vercmp(1.., 1.) - 0
new:
rpm.vercmp(1., 1) - 0
rpm.vercmp(1.., 1.) - 0
That's because I changed the loop from while (*one *two) to
while (*one || *two). The results are much saner with the change,
but we probably need to stay bug compatible. What do you think?
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--- lib/rpmvercmp.c.orig 2010-11-25 10:53:01.0 +
+++ lib/rpmvercmp.c 2010-11-25 11:45:02.0 +
@@ -32,9 +32,18 @@ int rpmvercmp(const char * a, const char
two = str2;
/* loop through each version segment of str1 and str2 and compare them */
-while (*one *two) {
- while (*one !risalnum(*one)) one++;
- while (*two !risalnum(*two)) two++;
+while (*one || *two) {
+ while (*one !risalnum(*one) *one != '~') one++;
+ while (*two !risalnum(*two) *two != '~') two++;
+
+ /* handle the tilde separator, it sorts before everthing else */
+ if (*one == '~' || *two == '~') {
+ if (*one != '~') return 1;
+ if (*two != '~') return -1;
+ one++;
+ two++;
+ continue;
+ }
/* If we ran to the end of either, we are finished with the loop */
if (!(*one *two)) break;
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Enforce install/erase order without adding a Requires:
Hi! There have been various issues with packages that demand a special order of installation but do not want to Require the package to be installed first. So a tag that is like Requires: during ordering but ignored otherwise is needed. Panu had a look into the problem yesterday and it turned out this can be done by simply adding a new tag triple and very few additional lines of code. But it also turned out that's really hard to come up with a good name for it. After banging our heads against the wall for the morning we settled on OrderWithRequires: It is not really beautiful but here are the reasons why we preferred it over two dozen other options: * It contains Requires which make clear that it is handled exactly like normal Requires during ordering. * We considered using Sort instead of Order as its less ambiguous but order is already part of the rpm nomenclature (--noorder). * It does not contain before or after which get wrong when it comes to ordering erases. * OrderWithRequires(pre) is supported and looks familiar. * It offers adding OrderWithRequiredBy later for adding a reverse relation. * It's long and descriptive. As it is going to be rarely used typing effort is not an argument. Nevertheless we still have the feeling there might be better names. Suggestions are welcome! Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Enforce install/erase order without adding a Requires:
On Thu, Nov 25, 2010 at 02:13:36PM +0100, FlorianFesti wrote:
There have been various issues with packages that demand a special order
of installation but do not want to Require the package to be installed
first. So a tag that is like Requires: during ordering but ignored
otherwise is needed.
OK, I'll bite. Can you list a few examples? I don't think I've
seen the need for this here at SUSE.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Enforce install/erase order without adding a Requires:
On Thu, 2010-11-25 at 14:13 +0100, FlorianFesti wrote: There have been various issues with packages that demand a special order of installation but do not want to Require the package to be installed first. So a tag that is like Requires: during ordering but ignored otherwise is needed. Panu had a look into the problem yesterday and it turned out this can be done by simply adding a new tag triple and very few additional lines of code. But it also turned out that's really hard to come up with a good name for it. After banging our heads against the wall for the morning we settled on OrderWithRequires: It is not really beautiful but here are the reasons why we preferred it over two dozen other options: * It contains Requires which make clear that it is handled exactly like normal Requires during ordering. * We considered using Sort instead of Order as its less ambiguous but order is already part of the rpm nomenclature (--noorder). * It does not contain before or after which get wrong when it comes to ordering erases. * OrderWithRequires(pre) is supported and looks familiar. * It offers adding OrderWithRequiredBy later for adding a reverse relation. * It's long and descriptive. As it is going to be rarely used typing effort is not an argument. Nevertheless we still have the feeling there might be better names. Suggestions are welcome! What about suggests or recommends (and enhances for the reverse)? I think almost any scenario where you want explicit order but not a hard dependency between packages falls into these categories. Thanks, Peter ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Enforce install/erase order without adding a Requires:
On 11/25/2010 02:20 PM, Peter Bowen wrote: What about suggests or recommends (and enhances for the reverse)? I think almost any scenario where you want explicit order but not a hard dependency between packages falls into these categories. Not exactly as they (where they are implemented - RPM upstream ist *still* missing them) carry additional semantics that is unwanted for this case. This tag is about ordering only. It does not tell whoever to include the other package into the transaction or bug the user to decide. But I agree that suggests, recommends and enhances should probably considered for ordering, too. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Enforce install/erase order without adding a Requires:
On Thu, 25 Nov 2010, FlorianFesti wrote: There have been various issues with packages that demand a special order of installation but do not want to Require the package to be installed first. So a tag that is like Requires: during ordering but ignored otherwise is needed. OrderWithRequires: It is not really beautiful ... The phrase 'do not want to Require the package' says to me: Suggests: -or- Enhances: which are basically saying a non-mandatory: Requires: It is my strong recollection that RPM previously had soft Requires. The rpm-list shows this in the thread from Peters around 10 Jan 2006 cAos and Mezzanine used it I think it was in part a response to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114338 What Trac or Bug number is driving this 'do not want to Require the package' 'functional requirement' so that I may review it, and try to understand why well known [from prior RPM experience and from Debian practice] (and not so ugly formulations) such as Suggests or Enhances are not preferred? -- Russ herrold ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Enforce install/erase order without adding a Requires:
On Thursday 25 November 2010, FlorianFesti wrote: Hi! There have been various issues with packages that demand a special order of installation but do not want to Require the package to be installed first. So a tag that is like Requires: during ordering but ignored otherwise is needed. Panu had a look into the problem yesterday and it turned out this can be done by simply adding a new tag triple and very few additional lines of code. But it also turned out that's really hard to come up with a good name for it. After banging our heads against the wall for the morning we settled on OrderWithRequires: It is not really beautiful but here are the reasons why we preferred it over two dozen other options: * It contains Requires which make clear that it is handled exactly like normal Requires during ordering. If it's actually not a Requires, it shouldn't IMO contain that word. If Suggests/Enhances are not desirable for this, how about DependencyOrder? Some actual, concrete example cases exactly what for and how this would be used might result in better suggestions. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
