Re: [Rpm-maint] RPM 4.9.0 alpha available
On 12/20/2010 06:07 PM, Michael Schroeder wrote: On Mon, Nov 29, 2010 at 07:13:38PM +0100, Michael Schroeder wrote: On Fri, Nov 19, 2010 at 11:44:53AM +0100, Michael Schroeder wrote: - tilde support in version comparison - triggers on provides instead of package names - weak dependencies (basically just parsing them and storing them in the rpm header) - defining some tag where yum/zypp/smart can store the reason why the package was installed (user selected/dragged in via dependencies), so that we can implement a show me all unneeded packages function Here's another one to discuss: - allow self-conflicts, like debian does. The use case is to be able to say only one of this may be installed. Example: And here's another nice-to-have feature (christmas is near ;-) ): - implement a way so that a directory may be replaced by a symlink to another directory. This is something packagers seem to do often, it happens when a directory gets moved for some reason and a compatibility symlink is added. Currently you'll get an ugly cpio error message when you try to install the rpm. There is probably no sane way to solve the general replace directory with something else problem, but the special case directory with symlink to directory may be possible. Maybe even directory with symlink to *new* directory is enough. Long time reader, first time poster (i think! ;)). Years ago i've had several cases of this and as you mentioned, a general solution isn't possible simply for the fact that rpm is lacking essential information and can do only syntax but not semantics of what you're trying to do. I've seen many many very very ugly hacks trying to circumvent the problem in packages (hint: %pre scripts with %ghost files *shudder*) to deal with really tricky changes. In general though it boils down to just a few cases actually: Post deinstall/pre install: 1) Directory is empty and not owned by any other package 2) Directory is empty and owned by other package[s] 3) Directory is not empty and neither it nor any of it's files are owned by other package[s] 4) Directory is not empty and it or any of it's files are owned by other package[s] I personally think 1) and 2) can be fairly sanely handled syntactically by rpm by simply removing the directory and adding that symlink. Case 3) and 4) though are imho not automagically solvable by rpm itself as there is no way rpm can determine what to do with the files in the directory. The only remotely sane handling would be to rename the directory to a dir.rpmsave and then let the admin handle the files within it, but that would be very optional and definitely not enabled by default. Default in such cases would still be to bomb out. The only thing that could really be improved there is if we could detect whether we'd end up with such a case during a transaction and basically abort it before we actually perform it. Otherwise we'll be stuck half performed transaction later on which is always kind of icky. Just my $0.02 Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. ___ 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 Mon, Nov 29, 2010 at 07:13:38PM +0100, Michael Schroeder wrote:
On Fri, Nov 19, 2010 at 11:44:53AM +0100, Michael Schroeder wrote:
- tilde support in version comparison
- triggers on provides instead of package names
- weak dependencies (basically just parsing them and storing them
in the rpm header)
- defining some tag where yum/zypp/smart can store the reason
why the package was installed (user selected/dragged in via
dependencies), so that we can implement a show me all unneeded
packages function
Here's another one to discuss:
- allow self-conflicts, like debian does. The use case is to
be able to say only one of this may be installed. Example:
And here's another nice-to-have feature (christmas is near ;-) ):
- implement a way so that a directory may be replaced by
a symlink to another directory.
This is something packagers seem to do often, it happens when
a directory gets moved for some reason and a compatibility symlink
is added. Currently you'll get an ugly cpio error message when
you try to install the rpm.
There is probably no sane way to solve the general replace
directory with something else problem, but the special case
directory with symlink to directory may be possible. Maybe
even directory with symlink to *new* directory is enough.
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] RPM 4.9.0 alpha available
On Fri, Nov 19, 2010 at 11:44:53AM +0100, Michael Schroeder wrote:
- tilde support in version comparison
- triggers on provides instead of package names
- weak dependencies (basically just parsing them and storing them
in the rpm header)
- defining some tag where yum/zypp/smart can store the reason
why the package was installed (user selected/dragged in via
dependencies), so that we can implement a show me all unneeded
packages function
Here's another one to discuss:
- allow self-conflicts, like debian does. The use case is to
be able to say only one of this may be installed. Example:
sendmail:
Provides: smtp_daemon
Conflicts: smtp_daemon
postfix:
Provides: smtp_daemon
Conflicts: smtp_daemon
rpm already allows self-obsoletes.
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] RPM 4.9.0 alpha available
On Thu, 25 Nov 2010, Michael Schroeder wrote: 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. At least these now behave as expected: RPMVERCMP(6.0~rc1, 6.0, -1) RPMVERCMP(6.0~rc1, 6.0~rc1, 0) RPMVERCMP(6.0~rc1, 6.0~rc1~git123, 1) RPMVERCMP(6.0~rc1~git123, 6.0~rc1, -1) Maybe somebody with more experience with the tilde use (from Debian side) could provide further/twistier example uses that can be used as test-cases... 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? That those should really return -ETYPO :) But as rpmvercmp() doesn't have an error return I agree the new results look saner and more consistent. I'm not aware of anything relying on the old behavior of trailing separators either, but that doesn't necessarily mean much. Anybody else, thoughts / commments? - 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 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
Re: [Rpm-maint] RPM 4.9.0 alpha available
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? - 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.) 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. (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. It would be much cleaner to put the strong versions in new tags. 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 weak versions are mostly hints to the layer on top of rpm, that say that if package A is selected it's good to also install B. Useful for anything that looks like a plugin, be it codecs, kernel drivers, language packages, ... - defining some tag where yum/zypp/smart can store the reason why the package was installed (user selected/dragged in via dependencies), so that we can implement a show me all unneeded packages function I'm fine with adding such a tag, as long as its defined in a way that it can be used by all the relevant depsolvers. We seem to have a pretty good attendance from the depsolver camps this time around... so: What such things are the depsolvers currently storing in their own databases, and in what format? The zypp stack currently doesn't store such information. The reason tag would seem to me to be an enum type basically (explicit request or dependency), so it'd be an integer in the header with some predefined RPM_FOO_* constants as its value? The other aspect is the how part: from C/C++, it's possible to add tags to the header from the transaction callback, but that wont work from python bindings at least. And also the callback is not a very friendly environment to do anything in any case... so it'd probably want some entirely new interface. I've a patch floating around someplace which permits transaction elements to carry an extra tags header which is merged to the actual package header at install time, but that's not necessarily the best approach either. An extra header is probably a bit overkill
Re: [Rpm-maint] RPM 4.9.0 alpha available
On 11/22/2010 04:35 AM, Bill Nottingham wrote: My pet idea is an informational tag is a tag that defines a package as either multilib or not-multilib, for use by distribution compose tools for packages to potentially opt-in or opt-out of whatever heuristics that such tools use. From a rpm developers point adding such a tag is not a big deal (assuming it is well defined and useful). But I doubt that this is really a good idea. My impression was that the general trend (in Fedora) is to move distribution policy decisions away from the packager and to a central point as they typically need deeper insight. That also lets packager do what they actually best in - building packages - without caring to much about high level release engineering topics. So putting information about package lists into the package looks like a move in the wrong direction. Also I got the feeling that rebuilding packages is considered painful. Possibly changing the package list late in the release process is a thing of it's own but also rebuilding the involved packages (that already got tested and passed qa) makes it even worse. But what finally spoils the idea IMHO is the fact that the same set of packages is used for different spins and products. Even if each spin has it's own packages list to overwrite the in-package decisions changing a package may have unwanted and hard to spot implications for the package list of the spins - like packages (including lots of dependencies) appearing from nothing or suddenly missing. As there will be the need of additional lists of exceptions why not stick the multilib packages in this lists just from the beginning or the PackageDB or some where else? As my knowledge about release engineering is very I might be wrong or overestimating these problems. Nevertheless they should be thought through before we add a tag that might just be unused (and confusing people) in the end. Florian ___ 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 Fri, 19 Nov 2010, Michael Schroeder wrote: On Fri, Nov 19, 2010 at 12:00:48PM +0200, Panu Matilainen wrote: We're closing in on another major RPM release, and compared to 4.7 and 4.8 the number of changes is so much bigger that we're starting with an alpha release instead of going directly to beta, just in case. As we're doing a major release, what are your thoughts on the following features: - 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 I dunno if the compatibility aspect is worth worrying about too much. There might be a handful of packages using ~ in version/release in the wild but common it is not, and it probably wouldn't be the end of the world if those got broken. Still it needs to be at least considered, even if the decision is just to ignore. - 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... 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. - 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 (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. 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... - defining some tag where yum/zypp/smart can store the reason why the package was installed (user selected/dragged in via dependencies), so that we can implement a show me all unneeded packages function I'm fine with adding such a tag, as long as its defined in a way that it can be used by all the relevant depsolvers. We seem to have a pretty good attendance from the depsolver camps this time around... so: What such things are the depsolvers currently storing in their own databases, and in what format? The reason tag would seem to me to be an enum type basically (explicit request or dependency), so it'd be an integer in the header with some predefined RPM_FOO_* constants as its value? The other aspect is the how part: from C/C++, it's possible to add tags to the header from the transaction callback, but that wont work from python bindings at least. And also the callback is not a very friendly environment to do anything in any case... so it'd probably want some entirely new interface. I've a patch floating around someplace which permits transaction elements to carry an extra tags header which is merged to the actual package header at install time, but that's not necessarily the best approach either. - 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 Mon, 2010-11-22 at 15:18 +0200, Panu Matilainen 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 I dunno if the compatibility aspect is worth worrying about too much. There might be a handful of packages using ~ in version/release in the wild but common it is not, and it probably wouldn't be the end of the world if those got broken. Still it needs to be at least considered, even if the decision is just to ignore. And we'll need to add support to yum-metadata-parser and createrepo to understand the new type. - defining some tag where yum/zypp/smart can store the reason why the package was installed (user selected/dragged in via dependencies), so that we can implement a show me all unneeded packages function I'm fine with adding such a tag, as long as its defined in a way that it can be used by all the relevant depsolvers. We seem to have a pretty good attendance from the depsolver camps this time around... so: What such things are the depsolvers currently storing in their own databases, and in what format? The reason tag would seem to me to be an enum type basically (explicit request or dependency), so it'd be an integer in the header with some predefined RPM_FOO_* constants as its value? reason from what repo/origin how_installed (meaning what command/program did the work) actually the set of things we might want to set is large. -sv ___ 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 Mon, 2010-11-22 at 09:46 -0500, seth vidal wrote: On Mon, 2010-11-22 at 15:18 +0200, Panu Matilainen 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 I dunno if the compatibility aspect is worth worrying about too much. There might be a handful of packages using ~ in version/release in the wild but common it is not, and it probably wouldn't be the end of the world if those got broken. Still it needs to be at least considered, even if the decision is just to ignore. And we'll need to add support to yum-metadata-parser and createrepo to understand the new type. actually, we won't - I was thinking of it being a change to the version FLAG and not to the version strings itself. -sv ___ 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
Michael Schroeder (m...@suse.de) said: As we're doing a major release, what are your thoughts on the following features: My pet idea is an informational tag is a tag that defines a package as either multilib or not-multilib, for use by distribution compose tools for packages to potentially opt-in or opt-out of whatever heuristics that such tools use. Bill ___ 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 Fri, Nov 19, 2010 at 12:00:48PM +0200, Panu Matilainen wrote:
We're closing in on another major RPM release, and compared to 4.7 and 4.8
the number of changes is so much bigger that we're starting with an alpha
release instead of going directly to beta, just in case.
As we're doing a major release, what are your thoughts on the
following features:
- tilde support in version comparison
- triggers on provides instead of package names
- weak dependencies (basically just parsing them and storing them
in the rpm header)
- defining some tag where yum/zypp/smart can store the reason
why the package was installed (user selected/dragged in via
dependencies), so that we can implement a show me all unneeded
packages function
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] RPM 4.9.0 alpha available
On 19.11.2010 12:44, Michael Schroeder wrote: On Fri, Nov 19, 2010 at 12:00:48PM +0200, Panu Matilainen wrote: We're closing in on another major RPM release, and compared to 4.7 and 4.8 the number of changes is so much bigger that we're starting with an alpha release instead of going directly to beta, just in case. As we're doing a major release, what are your thoughts on the following features: [...] - defining some tag where yum/zypp/smart can store the reason why the package was installed (user selected/dragged in via dependencies), so that we can implement a show me all unneeded packages function For the record, the above is implemented in urpmi (Mandriva) by storing a list of all the packages that are installed-through-deps in an external file. (I'm of course not against having it in rpmdb) -- Anssi Hannula ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
