[suggest] Re: suggest Digest, Vol 61, Issue 10

[Nico Kadel-Garcia]

Send suggest mailing list submissions to
? ? ? ?suggest at lists.rpmforge.net
To subscribe or unsubscribe via the World Wide Web, visit
? ? ? ?http://lists.rpmforge.net/mailman/listinfo/suggest
or, via email, send a message with subject or body 'help' to
? ? ? ?suggest-request at lists.rpmforge.net
You can reach the person managing the list at
? ? ? ?suggest-owner at lists.rpmforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of suggest digest..."
? ? ?glibc_date_format missing (Peter J. Holzer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Jul 2010 12:06:35 +0200
From: "Peter J. Holzer" <hjp+rpmforge at wsr.ac.at>
? ? ? ?glibc_date_format missing
To: suggest at lists.rpmforge.net
Message-ID: <20100719100635.GC29710 at wsr.ac.at>
Content-Type: text/plain; charset="iso-8859-1"

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,...

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.

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.

RPM is following a much older and far more reliable standard that
profoundly predates Perl. The idea that floating point numbers should
be used for version numbers is, historically, pretty odd.

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.

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?

Do what we've been doing with such modules for years. Insert a "."
after two digits.

In this case, we may have to put in a "Conflicts:" or even an
'Obsoletes' entry, at least for now, to get that 0.4501 out of hte
way".

[Nico Kadel-Garcia]

Send suggest mailing list submissions to
? ? ? ?suggest at lists.rpmforge.net
To subscribe or unsubscribe via the World Wide Web, visit
? ? ? ?http://lists.rpmforge.net/mailman/listinfo/suggest
or, via email, send a message with subject or body 'help' to
? ? ? ?suggest-request at lists.rpmforge.net
You can reach the person managing the list at
? ? ? ?suggest-owner at lists.rpmforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of suggest digest..."
? ? ?glibc_date_format missing (Peter J. Holzer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Jul 2010 12:06:35 +0200
From: "Peter J. Holzer" <hjp+rpmforge at wsr.ac.at>
? ? ? ?glibc_date_format missing
To: suggest at lists.rpmforge.net
Message-ID: <20100719100635.GC29710 at wsr.ac.at>
Content-Type: text/plain; charset="iso-8859-1"

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,...

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.

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.

RPM is following a much older and far more reliable standard that
profoundly predates Perl. The idea that floating point numbers should
be used for version numbers is, historically, pretty odd.

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.

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?

Do what we've been doing with such modules for years. Insert a "."
after two digits.

In this case, we may have to put in a "Conflicts:" or even an
'Obsoletes' entry, at least for now, to get that 0.4501 out of hte
way".

[Nico Kadel-Garcia]

Send suggest mailing list submissions to
? ? ? ?suggest at lists.rpmforge.net
To subscribe or unsubscribe via the World Wide Web, visit
? ? ? ?http://lists.rpmforge.net/mailman/listinfo/suggest
or, via email, send a message with subject or body 'help' to
? ? ? ?suggest-request at lists.rpmforge.net
You can reach the person managing the list at
? ? ? ?suggest-owner at lists.rpmforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of suggest digest..."
? ? ?glibc_date_format missing (Peter J. Holzer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Jul 2010 12:06:35 +0200
From: "Peter J. Holzer" <hjp+rpmforge at wsr.ac.at>
? ? ? ?glibc_date_format missing
To: suggest at lists.rpmforge.net
Message-ID: <20100719100635.GC29710 at wsr.ac.at>
Content-Type: text/plain; charset="iso-8859-1"

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,...

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.

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.

RPM is following a much older and far more reliable standard that
profoundly predates Perl. The idea that floating point numbers should
be used for version numbers is, historically, pretty odd.

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.

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?

Do what we've been doing with such modules for years. Insert a "."
after two digits.

In this case, we may have to put in a "Conflicts:" or even an
'Obsoletes' entry, at least for now, to get that 0.4501 out of hte
way".

[Nico Kadel-Garcia]

Send suggest mailing list submissions to
? ? ? ?suggest at lists.rpmforge.net
To subscribe or unsubscribe via the World Wide Web, visit
? ? ? ?http://lists.rpmforge.net/mailman/listinfo/suggest
or, via email, send a message with subject or body 'help' to
? ? ? ?suggest-request at lists.rpmforge.net
You can reach the person managing the list at
? ? ? ?suggest-owner at lists.rpmforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of suggest digest..."
? ? ?glibc_date_format missing (Peter J. Holzer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Jul 2010 12:06:35 +0200
From: "Peter J. Holzer" <hjp+rpmforge at wsr.ac.at>
? ? ? ?glibc_date_format missing
To: suggest at lists.rpmforge.net
Message-ID: <20100719100635.GC29710 at wsr.ac.at>
Content-Type: text/plain; charset="iso-8859-1"

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,...

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.

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.

RPM is following a much older and far more reliable standard that
profoundly predates Perl. The idea that floating point numbers should
be used for version numbers is, historically, pretty odd.

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.

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?

Do what we've been doing with such modules for years. Insert a "."
after two digits.

In this case, we may have to put in a "Conflicts:" or even an
'Obsoletes' entry, at least for now, to get that 0.4501 out of hte
way".

[Nico Kadel-Garcia]

Send suggest mailing list submissions to
? ? ? ?suggest at lists.rpmforge.net
To subscribe or unsubscribe via the World Wide Web, visit
? ? ? ?http://lists.rpmforge.net/mailman/listinfo/suggest
or, via email, send a message with subject or body 'help' to
? ? ? ?suggest-request at lists.rpmforge.net
You can reach the person managing the list at
? ? ? ?suggest-owner at lists.rpmforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of suggest digest..."
? ? ?glibc_date_format missing (Peter J. Holzer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Jul 2010 12:06:35 +0200
From: "Peter J. Holzer" <hjp+rpmforge at wsr.ac.at>
? ? ? ?glibc_date_format missing
To: suggest at lists.rpmforge.net
Message-ID: <20100719100635.GC29710 at wsr.ac.at>
Content-Type: text/plain; charset="iso-8859-1"

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,...

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.

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.

RPM is following a much older and far more reliable standard that
profoundly predates Perl. The idea that floating point numbers should
be used for version numbers is, historically, pretty odd.

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.

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?

Do what we've been doing with such modules for years. Insert a "."
after two digits.

In this case, we may have to put in a "Conflicts:" or even an
'Obsoletes' entry, at least for now, to get that 0.4501 out of hte
way".