[suggest] perl-DateTime-Format-Strptime-1.1000-1.el5.rf.noarch: glibc_date

Post by Gerd v. Egidy
Can't locate object method "glibc_date_format" via package
"DateTime::Locale::en_US" at
/usr/lib/perl5/vendor_perl/5.8.8/DateTime/Format/Strptime.pm line 780
After downgrading to perl-DateTime-Format-Strptime-1.1000-1.el5.rf.noarch
everything worked again.
Is this a problem in perl-DateTime-Format-Strptime-1.2000-1.el5.rf.noarch,
some missing dependency or some misconfiguration on my side?

the issue is the following:

1) the DateTime-Locale Perl distribution is generally versioned like 0.XX, 0.XY etc., as you can see from the Changelog:

http://cpansearch.perl.org/src/DROLSKY/DateTime-Locale-0.45/Changes

however, on May 19, 2008, the developer released version 0.4001, intending that version to sort between versions 0.40 and 0.41. from a Perlish standpoint, this is not unreasonable.

2) rpm's version comparison algorithm, however, sorts 0.4001 after 0.41 (Google for rpmvercmp if you want a more detailed explanation of why this is).

3) RPMforge has a perl-DateTime-Locale-0.4001 package, and many people (including you) have it installed on your system.

4) DateTime-Format-Strptime >= 1.2000 requires DateTime-Locale >= 0.45.

5) RPMforge has a perl-DateTime-Locale-0.45 package; however, yum (and rpm) don't see it as an available update because of point #2 above.

so, what's the fix for this situation? one fix is as follows:

$ yumdownloader perl-DateTime-Locale-0.45
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime
$ sudo rpm -U ./perl-DateTime-Locale-0.45*
$ sudo yum install perl-DateTime-Format-Strptime

after this, put an exclusion in your yum config so that your yum won't see the spurious perl-DateTime-Locale-0.4001 package. we intend to remove perl-DateTime-Locale-0.4001 from the repo entirely, and i'll post to the users list when that is done.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100715/96f930ad/attachment.bin

Gerd v. Egidy

2010-07-16 08:38:39 UTC

Hi Steve,

Post by Gerd v. Egidy
Can't locate object method "glibc_date_format" via package
"DateTime::Locale::en_US" at
/usr/lib/perl5/vendor_perl/5.8.8/DateTime/Format/Strptime.pm line 780

[...]

Thanks for your quick and detailed response.

Post by Steve Huff
$ yumdownloader perl-DateTime-Locale-0.45
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime
$ sudo rpm -U ./perl-DateTime-Locale-0.45*
$ sudo yum install perl-DateTime-Format-Strptime

I just used

yum downgrade perl-DateTime-Locale-0.45

and it worked like a charm.

Post by Steve Huff
after this, put an exclusion in your yum config so that your yum won't see
the spurious perl-DateTime-Locale-0.4001 package. we intend to remove
perl-DateTime-Locale-0.4001 from the repo entirely, and i'll post to the
users list when that is done.

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).

Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Kind regards,

Gerd

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Peter J. Holzer

2010-07-16 10:35:23 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

hp
--
_ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR | eingepr?gt stehen: "Ein ewig R?tsel will ich
| | | hjp at wsr.ac.at | bleiben, mir und andern."
__/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.repoforge.org/pipermail/users/attachments/20100716/dc82521f/attachment.bin

Christoph Maser

2010-07-17 12:33:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.
hp

I don't like that solution, the packages should have the same version as
upstream uses them.
We should at least remove the 4001 version from the pool.

+C

Peter J. Holzer

2010-07-19 10:06:35 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.

So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.

Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

And what do you do when the the maintainer releases version 0.5 next?
Remove all previous versions?

hp
--
_ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR | eingepr?gt stehen: "Ein ewig R?tsel will ich
| | | hjp at wsr.ac.at | bleiben, mir und andern."
__/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.repoforge.org/pipermail/users/attachments/20100719/e3abaea4/attachment.bin

Gerd v. Egidy

2010-07-19 13:53:05 UTC

Post by Peter J. Holzer
Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

And what do you do when the the maintainer releases version 0.5 next?
Remove all previous versions?

And how do we fix the systems, which currently have 4001 installed? Just
removing it from the repo won't help unless yum & rpm realize that there is a
newer version available.

I think it boils down to
a) increasing the epoch every time we have such an rpm-incompatible version
increase
b) Always use versions like 0.4500 when they have been used upstream once

How do other rpm-based distros solve this?

I could not find any hint for Fedora in
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version
and
http://fedoraproject.org/wiki/Packaging/Perl

Kind regards,

Gerd

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Steve Huff

2010-07-19 13:58:03 UTC

Post by Gerd v. Egidy
And how do we fix the systems, which currently have 4001 installed? Just
removing it from the repo won't help unless yum & rpm realize that there is a
newer version available.

at the very least, by talking about the issue in a public forum such as this one.

Post by Gerd v. Egidy
I think it boils down to
a) increasing the epoch every time we have such an rpm-incompatible version
increase
b) Always use versions like 0.4500 when they have been used upstream once
How do other rpm-based distros solve this?

Red Hat fixes this by bumping the Epoch. however, Red Hat doesn't have to worry about remaining compatible with an upstream distribution which may change without warning :)

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100719/eff748d7/attachment.bin

Steve Huff

2010-07-19 13:58:03 UTC

Post by Gerd v. Egidy
And how do we fix the systems, which currently have 4001 installed? Just
removing it from the repo won't help unless yum & rpm realize that there is a
newer version available.

at the very least, by talking about the issue in a public forum such as this one.

Steve Huff

2010-07-19 13:58:03 UTC

Post by Gerd v. Egidy
And how do we fix the systems, which currently have 4001 installed? Just
removing it from the repo won't help unless yum & rpm realize that there is a
newer version available.

at the very least, by talking about the issue in a public forum such as this one.

Steve Huff

2010-07-19 13:58:03 UTC

Post by Gerd v. Egidy
And how do we fix the systems, which currently have 4001 installed? Just
removing it from the repo won't help unless yum & rpm realize that there is a
newer version available.

at the very least, by talking about the issue in a public forum such as this one.

Steve Huff

2010-07-19 13:58:03 UTC

Post by Gerd v. Egidy
And how do we fix the systems, which currently have 4001 installed? Just
removing it from the repo won't help unless yum & rpm realize that there is a
newer version available.

at the very least, by talking about the issue in a public forum such as this one.

Red Hat fixes this by bumping the Epoch. however, Red Hat doesn't have to worry about remaining compatible with an upstream distribution which may change without warning :)

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/users/attachments/20100719/eff748d7/attachment.sig>

Dag Wieers

2010-07-19 15:47:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.

That is what we used to do, but in this case Steve wanted to obsolete to
one and only version (0.4001) and return to the upstream version numbers.
And I agreed with him because the problem is well-contained.

Post by Peter J. Holzer
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Using an epoch is a last resort measure that only upstream can use. If we
would use epoch and upstream introduces the same package with no epoch we
have no good way to ever go back.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Gerd v. Egidy

2010-07-19 13:53:05 UTC

Post by Peter J. Holzer
Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

And what do you do when the the maintainer releases version 0.5 next?
Remove all previous versions?

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Dag Wieers

2010-07-19 15:47:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.

Post by Peter J. Holzer
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Using an epoch is a last resort measure that only upstream can use. If we
would use epoch and upstream introduces the same package with no epoch we
have no good way to ever go back.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Gerd v. Egidy

2010-07-19 13:53:05 UTC

Post by Peter J. Holzer
Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

And what do you do when the the maintainer releases version 0.5 next?
Remove all previous versions?

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Dag Wieers

2010-07-19 15:47:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.

Post by Peter J. Holzer
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Using an epoch is a last resort measure that only upstream can use. If we
would use epoch and upstream introduces the same package with no epoch we
have no good way to ever go back.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Gerd v. Egidy

2010-07-19 13:53:05 UTC

Post by Peter J. Holzer
Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

And what do you do when the the maintainer releases version 0.5 next?
Remove all previous versions?

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Dag Wieers

2010-07-19 15:47:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.

Post by Peter J. Holzer
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Using an epoch is a last resort measure that only upstream can use. If we
would use epoch and upstream introduces the same package with no epoch we
have no good way to ever go back.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Gerd v. Egidy

2010-07-19 13:53:05 UTC

Post by Peter J. Holzer
Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

And what do you do when the the maintainer releases version 0.5 next?
Remove all previous versions?

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Dag Wieers

2010-07-19 15:47:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Well, in Perl terms that is the same version. Perl versions are floating
point numbers, so 0.45 == 0.450 == 0.4500 == 0.45000 and so on.
So a sequence of version numbers like 0.4, 0.4001, 0.45 is reasonable,
but rpm (which has to deal with many different versioning systems)
interpretes the version number not as a floating point number but as a
dot-separated series of integers. Writing the floating point number with
a fixed number of decimals fixes this.

Post by Peter J. Holzer
Increasing the epoch works, too. But I think that's a slight misuse of
the epoch system and it's easier to miss at an upgrade.

Using an epoch is a last resort measure that only upstream can use. If we
would use epoch and upstream introduces the same package with no epoch we
have no good way to ever go back.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Peter J. Holzer

2010-07-19 10:06:35 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

Peter J. Holzer

2010-07-19 10:06:35 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

Peter J. Holzer

2010-07-19 10:06:35 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

Peter J. Holzer

2010-07-19 10:06:35 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

I don't like that solution,

I don't like it either, but I think it's the least bad solution.

Post by Christoph Maser
the packages should have the same version as upstream uses them.

Post by Christoph Maser
We should at least remove the 4001 version from the pool.

And what do you do when the the maintainer releases version 0.5 next?
Remove all previous versions?

hp
--
_ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR | eingepr?gt stehen: "Ein ewig R?tsel will ich
| | | hjp at wsr.ac.at | bleiben, mir und andern."
__/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.repoforge.org/pipermail/users/attachments/20100719/e3abaea4/attachment.sig>

Christoph Maser

2010-07-17 12:33:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.
hp

I don't like that solution, the packages should have the same version as
upstream uses them.
We should at least remove the 4001 version from the pool.

+C

Christoph Maser

2010-07-17 12:33:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.
hp

I don't like that solution, the packages should have the same version as
upstream uses them.
We should at least remove the 4001 version from the pool.

+C

Christoph Maser

2010-07-17 12:33:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.
hp

I don't like that solution, the packages should have the same version as
upstream uses them.
We should at least remove the 4001 version from the pool.

+C

Christoph Maser

2010-07-17 12:33:53 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.
hp

I don't like that solution, the packages should have the same version as
upstream uses them.
We should at least remove the 4001 version from the pool.

+C

Peter J. Holzer

2010-07-16 10:35:23 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Peter J. Holzer

2010-07-16 10:35:23 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Peter J. Holzer

2010-07-16 10:35:23 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Peter J. Holzer

2010-07-16 10:35:23 UTC

Hmm. This would require everyone affected to manually fix it (with the
commands you used or the yum downgrade I used).
Wouldn't it make sense to increase the epoch for perl-DateTime-Locale-0.45?
This way yum would automatically know that 0.45 is the newer version and
upgrade to it. No manual steps involved, no more users asking what the problem
is,...

Alternatively, version 0.45 could be spelled 0.4500.

hp
--
_ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR | eingepr?gt stehen: "Ein ewig R?tsel will ich
| | | hjp at wsr.ac.at | bleiben, mir und andern."
__/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.repoforge.org/pipermail/users/attachments/20100716/dc82521f/attachment.sig>

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Gerd v. Egidy

2010-07-16 08:38:39 UTC

Hi Steve,

Post by Gerd v. Egidy
Can't locate object method "glibc_date_format" via package
"DateTime::Locale::en_US" at
/usr/lib/perl5/vendor_perl/5.8.8/DateTime/Format/Strptime.pm line 780

[...]

Thanks for your quick and detailed response.

I just used

yum downgrade perl-DateTime-Locale-0.45

and it worked like a charm.

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Gerd v. Egidy

2010-07-16 08:38:39 UTC

Hi Steve,

Post by Gerd v. Egidy
Can't locate object method "glibc_date_format" via package
"DateTime::Locale::en_US" at
/usr/lib/perl5/vendor_perl/5.8.8/DateTime/Format/Strptime.pm line 780

[...]

Thanks for your quick and detailed response.

I just used

yum downgrade perl-DateTime-Locale-0.45

and it worked like a charm.

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Gerd v. Egidy

2010-07-16 08:38:39 UTC

Hi Steve,

Post by Gerd v. Egidy
Can't locate object method "glibc_date_format" via package
"DateTime::Locale::en_US" at
/usr/lib/perl5/vendor_perl/5.8.8/DateTime/Format/Strptime.pm line 780

[...]

Thanks for your quick and detailed response.

I just used

yum downgrade perl-DateTime-Locale-0.45

and it worked like a charm.

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Gerd v. Egidy

2010-07-16 08:38:39 UTC

Hi Steve,

Post by Gerd v. Egidy
Can't locate object method "glibc_date_format" via package
"DateTime::Locale::en_US" at
/usr/lib/perl5/vendor_perl/5.8.8/DateTime/Format/Strptime.pm line 780

[...]

Thanks for your quick and detailed response.

I just used

yum downgrade perl-DateTime-Locale-0.45

and it worked like a charm.

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Christoph Maser

2010-07-17 12:28:04 UTC

Post by Steve Huff
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime

Propably better: rpm --oldpackage -U
perl-DateTime-Locale-0.45-1.el5.rf.noarch.rpm

+C

Steve Huff

2010-07-15 13:45:51 UTC

Gerd v. Egidy

2010-07-15 13:06:29 UTC

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Steve Huff

2010-07-15 13:45:51 UTC

Steve Huff

2010-07-15 13:45:51 UTC

Gerd v. Egidy

2010-07-15 13:06:29 UTC

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Steve Huff

2010-07-15 13:45:51 UTC

Steve Huff

2010-07-15 13:45:51 UTC

Gerd v. Egidy

2010-07-15 13:06:29 UTC

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Steve Huff

2010-07-15 13:45:51 UTC

Steve Huff

2010-07-15 13:45:51 UTC

Gerd v. Egidy

2010-07-15 13:06:29 UTC

--
Address (better: trap) for people I really don't want to get mail from:
jonas at cactusamerica.com

Steve Huff

2010-07-15 13:45:51 UTC

the issue is the following:

1) the DateTime-Locale Perl distribution is generally versioned like 0.XX, 0.XY etc., as you can see from the Changelog:

http://cpansearch.perl.org/src/DROLSKY/DateTime-Locale-0.45/Changes

however, on May 19, 2008, the developer released version 0.4001, intending that version to sort between versions 0.40 and 0.41. from a Perlish standpoint, this is not unreasonable.

2) rpm's version comparison algorithm, however, sorts 0.4001 after 0.41 (Google for rpmvercmp if you want a more detailed explanation of why this is).

3) RPMforge has a perl-DateTime-Locale-0.4001 package, and many people (including you) have it installed on your system.

4) DateTime-Format-Strptime >= 1.2000 requires DateTime-Locale >= 0.45.

5) RPMforge has a perl-DateTime-Locale-0.45 package; however, yum (and rpm) don't see it as an available update because of point #2 above.

so, what's the fix for this situation? one fix is as follows:

$ yumdownloader perl-DateTime-Locale-0.45
$ sudo rpm -e --nodeps perl-DateTime-Locale perl-DateTime-Format-Strptime
$ sudo rpm -U ./perl-DateTime-Locale-0.45*
$ sudo yum install perl-DateTime-Format-Strptime

after this, put an exclusion in your yum config so that your yum won't see the spurious perl-DateTime-Locale-0.4001 package. we intend to remove perl-DateTime-Locale-0.4001 from the repo entirely, and i'll post to the users list when that is done.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/users/attachments/20100715/96f930ad/attachment.sig>

Steve Huff

2010-07-15 13:45:51 UTC