Subject: Fedora Core 2 Test Update: dovecot-0.99.10.6-1,FC2,1
--------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-201 2004-06-30 ---------------------------------------------------------------------
Product : Fedora Core 2 Name : dovecot Version : 0.99.10.6 Release : 1,FC2,1 Summary : Dovecot Secure imap server Description : Dovecot is an IMAP server for Linux/UNIX-like systems, written with security primarily in mind. It also contains a small POP3 server. It supports mail in either of maildir or mbox formats.
--------------------------------------------------------------------- Update Information:
- bring up to date with upstream, recent change log comments from Timo Sirainen were: SHA1 password support using OpenSSL crypto library mail_extra_groups setting maildir_stat_dirs setting Added NAMESPACE capability and command Autocreate missing maildirs (instead of crashing) Fixed occational crash in maildir synchronization Fixed occational assertion crash in ioloop.c Fixed FreeBSD compiling issue Fixed issues with 64bit Solaris binary --------------------------------------------------------------------- * Wed Jun 30 2004 John Dennis jdennis@redhat.com
- bump rev for build
* Fri Jun 25 2004 John Dennis jdennis@redhat.com - 0.99.10.6-1
- bring up to date with upstream, recent change log comments from Timo Sirainen were: SHA1 password support using OpenSSL crypto library mail_extra_groups setting maildir_stat_dirs setting Added NAMESPACE capability and command Autocreate missing maildirs (instead of crashing) Fixed occational crash in maildir synchronization Fixed occational assertion crash in ioloop.c Fixed FreeBSD compiling issue Fixed issues with 64bit Solaris binary
* Tue Jun 15 2004 Elliot Lee sopwith@redhat.com
- rebuilt
--------------------------------------------------------------------- This update can be downloaded from:
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/
749a821b0a6da99c28b2325fade72024 SRPMS/dovecot-0.99.10.6-1,FC2,1.src.rpm 3561cd5dfa250f26a67298c7bb5c840a x86_64/dovecot-0.99.10.6-1,FC2,1.x86_64.rpm d1ee606f3f126e71e83cfefc7fa19378 x86_64/debug/dovecot-debuginfo-0.99.10.6-1,FC2,1.x86_64.rpm 5af0bae46300fb9c1b6d34424ae9f5d7 i386/dovecot-0.99.10.6-1,FC2,1.i386.rpm 847d50fcf8648960058d33d270d73d4e i386/debug/dovecot-debuginfo-0.99.10.6-1,FC2,1.i386.rpm
This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. You may need to edit your up2date channels configuration. Within /etc/sysconfig/rhn/sources enable the following line: yum updates-testing http://fedora.redhat.com/updates/testing/fedora-core-2 ---------------------------------------------------------------------
On Thu, 2004-07-01 at 11:00 -0400, John Dennis wrote:
Subject: Fedora Core 2 Test Update: dovecot-0.99.10.6-1,FC2,1
Fedora Test Update Notification FEDORA-2004-201 2004-06-30
Product : Fedora Core 2 Name : dovecot Version : 0.99.10.6 Release : 1,FC2,1 <---- What is this?????????????? Summary : Dovecot Secure imap server Description :
<SNIP>
Please don't continue using these Release strings, all it does it break things...
-sb
-- John Dennis jdennis@redhat.com
On Thu, 2004-07-01 at 13:22, Stan Bubrouski wrote:
Release : 1,FC2,1 <---- What is this??????????????
Please don't continue using these Release strings, all it does it break things...
We've been having an internal discussion recently about how to make the release field meaningful. In the past it was typically an integer, which had no meaning in the context of multiple simultaneous distributions. In the last year or two some packages have started encoding strings into the release such as AS, RHEL3, FC1, etc. Is it this practice you are referring to in general or the specific case cited above? What specifically is breaking?
No assumptions should be made about the format of the release string other than it collate correctly when presented to rpmvercmp (the comparison function in rpm which has specific well defined semantics).
For what its worth, it's been noted that it is a deficiency n-v-r does not contain build information within a distribution. Using simple integers as the release yields arbitrary mappings of integers to distributions and builds(patches, errata) within a given distribution.
Unfortunately we are pretty much stuck with n-v-r for historical reasons. However it is felt the r part of n-v-r can be encoded with more information while preserving n-v-r format which many utilities have come to expect.
Are you experiencing a problem with a utility that is expecting the r part of n-v-r to be numeric or a utility that is not using rmpvercmp or implementing the logic in rpmvercmp?
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
No assumptions should be made about the format of the release string other than it collate correctly when presented to rpmvercmp (the comparison function in rpm which has specific well defined semantics).
How you are using rpmvercmp, say, in a shell script? AFAIK there is no interface which would make that available. Or this is one of those undocumented mysteries of rpm?
Unfortunately we are pretty much stuck with n-v-r for historical reasons.
This I can reliably pick apart using --queryformat but now what?
In case you wonder if I need that in shell scripts and similar then the answer is that indeed I do (and many others too). A comparison utility which would compare (or even collate but that I can do myself) according to rpmvercmp would be really useful.
Michal
On Thu, 2004-07-01 at 16:28, Michal Jaegermann wrote:
How you are using rpmvercmp, say, in a shell script? AFAIK there is no interface which would make that available.
This is off-topic for this list, but I'll answer it here, further discussion should be moved to the fedora list.
You can use the rpm python bindings, see attached script (rpmvercmp.py).
Please note, internally the algorithm is:
name is tested for equality epoch is numerically compared version is passed to rpmvercmp release is passed to rpmvercmp
first definitive answer is returned
rpmvercmp splits the string into alphanumeric substrings, then pairwise compares them, numerically if the leading char is a digit, lexically otherwise, pairwise comparison ends on first definitive result.
Credit and thanks go to Jerry Katz who showed me the python bindings and patiently explained many things to me.
Also attached is a tiny C program I wrote that will operate on strings rather than reading the rpm header's. It's good for when you just want to test rpm names as strings and don't have a full rpm, you can give it a pair of n-v-r, in which case it calls rpmvercmp on version and then release, or you can give it either just a pair of versions or a pair of revisions and it will call rpmvercmp on just that component. It links against rpm so it uses the actual rpmvercmp function.
On Thu, Jul 01, 2004 at 07:16:31PM -0400, John Dennis wrote:
On Thu, 2004-07-01 at 16:28, Michal Jaegermann wrote:
How you are using rpmvercmp, say, in a shell script? AFAIK there is no interface which would make that available.
You can use the rpm python bindings, see attached script (rpmvercmp.py).
Thanks. This will be useful.
Credit and thanks go to Jerry Katz who showed me the python bindings and patiently explained many things to me.
Right. Unfortunately JK does not come bundled in rpm, even in rawhide, so this resource is not widely available. :-)
Michal
On Thu, 1 Jul 2004, John Dennis wrote:
On Thu, 2004-07-01 at 16:28, Michal Jaegermann wrote:
How you are using rpmvercmp, say, in a shell script? AFAIK there is no interface which would make that available.
This is off-topic for this list, but I'll answer it here, further discussion should be moved to the fedora list.
Yack...thought this was the rpm list. That said my comment concerning previous post of mine on this list should instead refer to the rpm list.
Cheers...james
On Jul 1, 2004, Michal Jaegermann michal@harddata.com wrote:
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
No assumptions should be made about the format of the release string other than it collate correctly when presented to rpmvercmp (the comparison function in rpm which has specific well defined semantics).
How you are using rpmvercmp, say, in a shell script? AFAIK there is no interface which would make that available. Or this is one of those undocumented mysteries of rpm?
I wrote this years ago for a script that would automatically install updates from a local mirror of the Red Hat Linux updates site. Except that I just updated it to support commas as separators; I'd no idea they could be used with the same meaning as dots before the internal discussion :-)
Untested after the change to support commas. Hope this helps.
# Copyright 1999, 2000, 2001, 2002, 2004 # Alexandre Oliva oliva@lsd.ic.unicamp.br
# This script is Free Software, and it can be copied, distributed and # modified as defined in the GNU General Public License. A copy of # its license can be downloaded from http://www.gnu.org/copyleft/gpl.html
newer () { test "x$1" != "x$2" && case "$1$2" in *-*) newer "`echo $1 | sed 's/-.*//'`" "`echo $2 | sed 's/-.*//'`" || { test "`echo $1 | sed 's/-.*//'`" = "`echo $2 | sed 's/-.*//'`" && newer "`echo $1 | sed 's/[^-]*-*//'`" "`echo $2 | sed 's/[^-]*-*//'`"; } ;; *[.,]*) newer "`echo $1 | sed 's/[.,].*//'`" "`echo $2 | sed 's/[.,].*//'`" || { test "`echo $1 | sed 's/[.,].*//'`" = "`echo $2 | sed 's/[.,].*//'`" && newer "`echo $1 | sed 's/[^.,]*.*//'`" "`echo $2 | sed 's/[^.,]*.*//'`"; } ;; *) result=false if test -x $SORT; then { echo $2; echo $1; } | $SORT -n -c > /dev/null 2>&1 && result=true else test $1 -gt $2 && result=true fi $result ;; esac }
# usage: if newer r1-v1 r2-v2; then echo r1-v1 is newer; fi
On Thu, 1 Jul 2004, Michal Jaegermann wrote:
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
No assumptions should be made about the format of the release string other than it collate correctly when presented to rpmvercmp (the comparison function in rpm which has specific well defined semantics).
How you are using rpmvercmp, say, in a shell script? AFAIK there is no interface which would make that available. Or this is one of those undocumented mysteries of rpm?
Hi Michal, look back through the messages about a month and you will see a message concerning rpm package versions that I answered that pretty muchh answers your question. In short its pretty easy to use the python bindings or perl (RPM2) bindings to librpm to access rpmvercmp(). In my original post, I think I gave a short inline perl example (i.e. a tiny script using perl -e option to pass the script from the command line). I definately do this at my work in various shell scripts.
Cheers..james
Unfortunately we are pretty much stuck with n-v-r for historical reasons.
Yep and you cannot forget epoch.
This I can reliably pick apart using --queryformat but now what?
In case you wonder if I need that in shell scripts and similar then the answer is that indeed I do (and many others too). A comparison utility which would compare (or even collate but that I can do myself) according to rpmvercmp would be really useful.
Again search back through the archives and you will see code to that effect. Really what would be quite handy though for shell scripts is a utility that could be called in the following ways:
rpmvercmp -v 1.1.1 -v 1.1.2 rpmvercmp -p x-1.1.1-2.0.i386.rpm -d rpmvercmp -p x-1.1.1-2.0.i386.rpm -p x-1.1.2-1.1.i386.rpm rpmvercmp -p x-1.1.1-2.0.i386.rpm -v 1.1.2 rpmvercmp -n x -v 1.1.2 -d
So basically, allow you to compare a:
- E:V-R string to an E:V-R string, - package to the package in the db - package to another package. - package to an E:V-R string - E:V:R string for a specific N to the database.
Would not be too hard to create such a script from RPM2 (and I suspect easy to do so with the python bindings). Unfortunately, I am tied up in non-rpm endevours at the moment, or I would gladly wip it up and send it to the list. Maybe tonight I will have time, but no promises.
Cheers...james
Michal
On Thu, Jul 01, 2004 at 02:23:53PM -0400, John Dennis wrote:
On Thu, 2004-07-01 at 13:22, Stan Bubrouski wrote:
Release : 1,FC2,1 <---- What is this??????????????
Please don't continue using these Release strings, all it does it break things...
We've been having an internal discussion recently about how to make the release field meaningful. In the past it was typically an integer, which had no meaning in the context of multiple simultaneous distributions. In the last year or two some packages have started encoding strings into the release such as AS, RHEL3, FC1, etc. Is it this practice you are referring to in general or the specific case cited above? What specifically is breaking?
Let me invent a statistic: 99% of all packages produced by everyone ever use '.' as a component separator in release/version/etc fields - it is an accepted convention.
The question is: why be inconsistent with all those packages, and start using a comma? It makes no difference to rpmvercmp, it still treats the field as three separate segments.
joe
On Thu, 01 Jul 2004 14:23:53 -0400, John Dennis wrote:
On Thu, 2004-07-01 at 13:22, Stan Bubrouski wrote:
Release : 1,FC2,1 <---- What is this??????????????
Please don't continue using these Release strings, all it does it break things...
We've been having an internal discussion recently about how to make the release field meaningful.
Why not a public discussion on fedora-devel-list?
On Fri, Jul 02, 2004 at 02:58:20PM +0200, Michael Schwendt wrote:
We've been having an internal discussion recently about how to make the release field meaningful.
Why not a public discussion on fedora-devel-list?
Because most of it related to internal build systems, the enterprise product and the like