Jesse Keating wrote:
On Wednesday 12 July 2006 15:52, Nicolas Mailhot wrote:
If you move it to the version you're breaking jpp -> fc upgrade paths
If you put it as Provides it's ok from the package manager POW but not
for users (there are reasons why we use long descriptive filenames and
not DOS-like 8:3 names)
In which ways are we breaking it? jpp has foo-2.6.0-6jpp. Fedora has
foo-2.6.0.6jpp-1.fc6.
Why?
I've answered your question, you did not answer mine.
2.6.0.6 is rpmnewer than 2.6.0-6, upgrade path exists.
Where does the version ends and the relase begins in this?
6jpp is part of the release, not the version, and it can be prefixed.
What do you do with foo-2.7-0.cvs20060123.4jpp ?
If jpp issues 2.6.0-7jpp, its going to be newer than what FC provides yes,
but do we want users picking up that package? Shouldn't they stay with the
FC provided one? Or do you want it replaced and then replaced again when FC
bumps the package?
We want the upstream package to take precedence, as fixes go there
first. Once we import that version and produce a pre-compiled (AOT)
equivalent, that takes precedence.
So then put it in the name rather than the version.
"Upstream": foo-2.6.0-6jpp
Name: foo-6jpp
Version: 2.6.0
Release: 1%{?dist}
Provides: foo = 2.6.0-6jpp
Versions in package names? The namespace will explode in no time, no
history, imagine adding new packages all the time to the bug repository
lists, and so on. Huge implications.
We do have a few release-marked packages but that is done only as an
extreme measure due to incompatible API changes and usually for a
limited time (the versioned package is just kept for backward
compatibility purposes for the least possible time).
Regards,
Fernando
