Warren's Package Naming Proposal - Revision 2

[Warren Togami]

http://www.fedora.us/wiki/PackageNamingGuidelines
The following is based upon current fedora.us package naming guidelines,
edited and dramatically simplified because fedora.redhat.com no longer
needs many of fedora.us special considerations.

http://www.redhat.com/archives/fedora-devel-list/2003-October/msg01152.html
This is Revision 1 from October 31st, 2003

The below proposal is ALMOST EXACTLY THE SAME as fedora.us current
scheme except with the leading "0.fdr." removed from all %{release} tags
and %{reptag} added to the end. I would assert that fedora.us package
naming scheme has demonstrated to be a great success, thus it should
continued in fedora.redhat.com. The below scheme is also in-line with
the common practices used by most of Red Hat's existing packages.

Dispersed within the below draft are "XXX" sections where discussions
are still necessary. The revision history of section iii otherwise
notes sections that have been changed since Revision 1. Section C-7 at
the bottom is the most important part in this revision.



**Fedora Package Naming Guidelines
Warren's Proposal for fedora.redhat.com
Revision 2
================================
i. Introduction
Goals for package naming guidelines
ii. Terminology
iii. Revision History
A. Package Name
B. Version
C. Release Tag
1. Release Prefix
2. Vepoch
3. Non-Numeric Version to Release
4. Dist tag
5. Special: Kernel modules
6. Special: Plugin, theme etc packages
7. Special: Repository Tag

i. Introduction
===============
Goals for the Fedora Package Naming Guidelines
* Easily understandable package naming policy
* Indication of the original source version (end-user convenience)
* Allow for a smooth upgrade path between multiple levels of testing
branches and future distribution upgrades. This means E-V-R must never
be exactly identical between distribution versions.
* Minimize the chance of package conflicts for future Fedora
distribution upgrades.

ii. Terminology
==============
name
This is the "Name" field of RPM .spec files.

version
This is the "Version" field of RPM .spec files.

release tag
This is the "Release" field of RPM .spec files.

dist tag
This is a distribution tag indicating which RHL/FC distribution this
package is intended for. This only occurs in cases where packages from
different distributions are built from the same SRPM and patchlevel.

vepoch
This is our term for "version specific epoch", used in all packages as a
simple means of ensuring upgrades by simple incrementing the leading
number within the release tag. vepoch is otherwise known as "release
number" or "patchlevel". Read C-2 for more information.

XXX: For now I am keeping the term vepoch in this draft because a better
alternative has not been proposed. I personally feel that "release
number" most effectively communicates what this number is about, however
"release number" is confusingly similar to "release tag" no? "release
tag" == %{release}
Please discuss this... we need only choose a name to replace vepoch.
XXX

E-V-R
Abbreviation for epoch, version, and release. This is often referred to
when talking about potential package upgrading problems.


iii. Revision History
=====================
07 October 2003 Draft Revision 2
* C-7 minor number is now %{reptag} for marking repositories and 3rd
party repositories.
* Many XXX sections needing discussion before changes in Draft Revision 3.
31 October 2003 Draft Revision 1.
* Initial post for fedora.redhat.com.



A. Package Name
===============
Package name should preferably match the upstream tarball or project
name from which this software came. In some cases this naming choice is
more complicated. If this package has been packaged by other
distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS,
etc.) in the past, then we should try to match their name for
consistency. In any case, try to use your best judgment, and other
developers will help in the final decision.

Ultimately it is up to QA to decide upon the proper %{name} before
publication.

B. Version
==========
If the version is only numbers, then these numbers can be put into the
"version" field of the RPM .spec unchanged. If the version contains
non-numeric characters, this creates several problems for RPM version
comparison and a broken upgrade path.

Example:
foobar-1.2.3beta1.tar.gz
foobar-1.2.3.tar.gz

While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM
version comparison thinks the former is newer.

Example:
foobar-1.0a
foobar-1.0b

The "1.0b" version is higher than "1.0a", but all versions of RPM prior
to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever
package is first in the comparison "wins", thus this becomes a two way
upgrade problem. This a < b comparison works properly only in RH9 and
higher.

For simplicity, Fedora treats both pre-release and post-release
non-numeric version cases the same, making the version purely numeric
and moving the alphabetic part to the release tag. Take the numeric
portion of the source version and make that the package version tag.

Read C-3 for more details.

XXX:
Read section C-3 for the very important discussion necessary for
removing the post-release requirement in non-numeric %{version} tags.
XXXX

C. Release Tag
==============
The release tag of Fedora packages more complicated, so this is split
into several parts.

C-1. Release Prefix
-------------------
No longer needed in fedora.redhat.com.

C-2. Vepoch
-----------
The leftmost leading number within the release tag is the "version
specific epoch" or vepoch in Fedora. This number is incremented with
every package update. The vepoch is otherwise known as the "release
number" or "patchlevel".

The key difference between the concept of "vepoch" and "patch level" is
that everything to the right of the vepoch is PURELY INFORMATIONAL. The
only time where it matters is to guarantee a different %{release} tag
between two distribution versions.

The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy
as canonical. Package updates in any repository should always check all
other official repositories to be sure that the vepoch is always
incremented and never matching an existing package.

With most normal packages, vepoch is a single number starting at "1".
Under the (C-3) non-numeric version case it is two numbers starting at
"0.1" with the second number being the number to increment.

Normal Package Example:
foobar-1.2.3-1.src.rpm compiles to
foobar-1.2.3-1.i386.rpm

If this package is patched:
foobar-1.2.3-2.i386.rpm
foobar-1.2.3-3.i386.rpm

XXX:
Read section ii. near the top regarding the discussion necessary in
renaming of vepoch within the naming guidelines.
XXX


C-3. Non-Numeric Version to Release
-----------------------------------
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
versioned packages can be problematic so they must be treated with care.
These are cases where the upstream version has letters rather than
simple numbers in their version. Often they have tags like alpha, beta,
rc, or letters like a and b denoting that it is a version before or
after the number. Read section B to understand why we cannot simply put
these letters into the version tag.

Release Tag for Pre-Release Packages:
0.%{X}.%{alphatag}
Release Tag for Non-Numeric Post-Release Packages:
%{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.

Example (pre-release):
mozilla-1.4a.tar.gz from upstream is lower than
mozilla-1.4.tar.gz the later "final" version thus
mozilla-1.4-0.1.a Fedora package name

Example (pre-release):
alsa-lib-0.9.2beta1.tar.gz becomes
alsa-lib-0.9.2-0.1.beta1

Example (post-release):
gkrellm-2.1.7.tar.gz
gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7
gkrellm-2.1.7-1.a

Upgrade Path Example (mozilla):
mozilla-1.4-0.1.a
Patched
mozilla-1.4-0.2.a
Patched again
mozilla-1.4-0.3.a
Move to 1.4b
mozilla-1.4-0.4.b
Patched
mozilla-1.4-0.5.b
Move to 1.4 "final" version
Notice that this becomes a normal C-2 case
mozilla-1.4-1
Patched
mozilla-1.4-2

Upgrade Path Example (alsa-lib):
alsa-lib-0.9.2-0.1.beta1
Patched
alsa-lib-0.9.2-0.2.beta1
Move to beta2
alsa-lib-0.9.2-0.3.beta2
Move to beta3 and simultaneously patch
alsa-lib-0.9.2-0.4.beta3
Patched again
alsa-lib-0.9.2-0.5.beta3
Move to rc1
alsa-lib-0.9.2-0.6.rc1
Move to rc2
alsa-lib-0.9.2-0.7.rc2
Move to "final"
alsa-lib-0.9.2-1
Patched
alsa-lib-0.9.2-2

XXX: Please discuss this:
We should change the post-release case to no longer be effected by the
non-numeric %{version} rule since rpm-4.2 in RH9 and higher are not
effected by this problem. Furthermore (and by accident) rpm python
bindings since rpm-4.1 of RH8 have behaved in a proper fashion while rpm
itself did not, and apt-get has always behaved "properly" when comparing
numbers to letters, or letters to letters. In any case Fedora Legacy
has already agreed that upgrading rpm to the latest version must be done
as the first requirement for all users who will be using Fedora Legacy.

For these reasons we probably *can* allow non-numeric characters into
the version only in certain cases where it is ABSOLUTELY CERTAIN it will
not lead to an epoch increment in the future.

Mike Harris brought up the example of the "imap" package with its
strange versioning. In some cases like that, we may need to grandfather
some packages in.
This point needs a LOT more analysis before being ratified, so please
discuss this. Do not contribute to this part of the thread unless you
truly know what you are talking about. No speculation please.
XXX


C-4. Dist tag
-------------
In cases where the same SRPM and patchlevel is used between two or more
distributions supported by Fedora, a dist tag is appended to the end of
the release tag defined in C-2 and C-3. The dist tags with the
following examples appear to be only cosmetic, however the a different
E-V-R is needed between distributions to ensure dist upgrading works
fully in all corner cases.

Dist Tag for Normal Packages:
%{X}.%{disttag}
Where %{X} is the vepoch and %{disttag} is a distribution tag from this
table:

0.7.3 Red Hat Linux 7.3
0.8 Red Hat Linux 8
0.9 Red Hat Linux 9
1 Fedora Core 1
1.93 Fedora Core 1.93 beta
1.94 Fedora Core 1.94 beta
2 Fedora Core 2 beta

Example:
foobar-1.2.3-1.0.7.3.i386.rpm
foobar-1.2.3-1.0.8.i386.rpm
foobar-1.2.3-1.0.9.i386.rpm
foobar-1.2.3-1.1.94.i386.rpm
foobar-1.2.3-1.2.i386.rpm

Upgrade Path Example (FC1 only shown):
foobar-1.2.3-1.1.i386.rpm
foobar-1.2.3-2.1.i386.rpm
foobar-1.2.3-3.1.i386.rpm


Dist Tag for Pre-Release Packages:
%{X}.%{alphatag}.%{disttag}
Where %{X} is the vepoch, %{alphatag} is the pre-release tag described
in C-3, %{disttag} is a distribution tag described above.

Example:
alsa-lib-0.9.2-0.1.beta1.0.8.i386.rpm
alsa-lib for RH 8.0
alsa-lib-0.9.2-0.1.beta1.1.i386.rpm
alsa-lib for FC1

Upgrade Path Example (RH 7.3 only shown):
alsa-lib-0.9.2-0.1.beta1.0.7.3
alsa-lib-0.9.2-0.2.beta1.0.7.3
alsa-lib-0.9.2-0.3.beta2.0.7.3
alsa-lib-0.9.2-0.4.beta3.0.7.3
alsa-lib-0.9.2-0.5.beta3.0.7.3
alsa-lib-0.9.2-0.6.rc1.0.7.3
alsa-lib-0.9.2-0.7.rc2.0.7.3
alsa-lib-0.9.2-1.0.7.3
alsa-lib-0.9.2-2.0.7.3

XXX:
I replaced all of the underscores with periods due to the "ugly"
reactions from the last draft. Yeah, there isn't a lot of logic behind
"ugly" and having a different delimiter might make it easier to read,
but I would suggest sticking with the period for these reasons:
1) Everyone thinks the underscores were ugly.
2) disttag is always at the end, so there is no confusion.
3) except... when it is a 3rd party repository where the reptag is at
the end. But that isn't so confusing.
Discuss this if you want, but be prepared for more whining about "ugly!"
XXX

C-5. Special Case: Kernel modules
---------------------------------
XXX:
This section still needs much discussion. Later.
XXX

C-6. Plugin, theme etc packages
-------------------------------
Packages that are plugins, themes or the like, ie. enhance other
packages must be named <package-to-enhance>-<enhancement>. If the
resulting name differs significantly from upstream naming, a
Provides: <upstream-name> = %{epoch}:%{version}-%{release}
must be added. For example:

Upstream package name: modplug-xmms
Fedora package name: xmms-modplug
Provides: modplug-xmms = %{epoch}:%{version}-%{release}

XXX:
Should we actively discourage packages that *appear* to be plugin,
add-on or theme packages but are actually completely independent? One
example that has caught me off guard lately was Dag's mozilla-firebird
package. While Dag published mozilla-firebird, fedora.us decided
against a name change from MozillaFirebird to mozilla-firebird for these
reasons:
1) No reason to change.
2) Mozilla branding strategy document said the name was changing "soon"
anyway, (which still hasn't happened.)
3) mozilla-firebird is within the long implicitly understood and
fedora.us codified standard of being a component or add-on to "mozilla",
which is clearly wrong in this case.
#2 and #3 were the strongest arguments in my opinion.

I can't think of any other past examples off the top of my head, but I
really want to avoid these kinds of instances in the future if
possible. Please express your opinions.
XXX

C-7. Repository Tag
-------------------
Repository tags are appended to the end of %{release} tags for any
packages not within Fedora Core or Fedora Extras. FC and FE are
excluded because Fedora Core should never contain the same %{name}
package as Fedora Extras, and vice-versa. All external and 3rd party
repositories NEED repository tags. Fedora Alternatives and Fedora
Legacy are to use rep tags.

Repository Tag for Normal Packages:
%{X}.%{disttag}.%{reptag}
Where %{X} is the vepoch and %{disttag} is a distribution tag defined in
C-4, and reptag is an alphanumeric string standardized and unique for a
repository.

XXX:
The below examples are using theoretical reptags.
XXX

Fedora Legacy: apache for RH7.3
apache-1.3.27-4.0.7.3.legacy
Fedora Alternatives: Beowulf for FC2
kernel-2.6.2-3.2.beowulf
beowulf-pxe-images-2.3-2.2.beowulf
cluster-foo-libs-1.7-2.2.beowulf
cluster-foo-tools-1.7-2.2.beowulf
cluster-foo-devel-1.7-2.2.beowulf
freshrpms: 3rd party packages for FC1
diradmin-1.5.1-2.1.fr
AtRPMS: 3rd party packages for FC1
perl-HTML-Tree-3.18-4.1.at
DAG: 3rd party packages for FC1
distcc-2.11.1-1.1.dag
Livna: 3rd party packages for FC1
foogame-3.3-3.beta3.1.lvn
fooutil-2.1-4.1.lvn
fooapplet-1.0-9.rc4.1.lvn
kde-redhat: 3rd party Uncrippled KDE packages for FC1
kdebase-3.1.4-7.1.kderedhat

Note that it is the 3rd party or Alternatives choice of what %{X} number
to use. If they use the same %{X} number as the canonical FC/FE
packages they are superceding, then any future upgrade upstream is
guaranteed to superceed the 3rd party or Alternatives package. This can
be desired or not.


XXX:
The 3 points below need to be worked into the document above
somewhere... too tired to do that at the moment... discuss for now.

Caveats!
1) Fedora Core and Fedora Extras are to be considered canonical. All
other repositories must respect the vepoch of the canonical
repositories, however FC and FE may choose to ignore 3rd parties when
incrementing the vepoch for a new package release.
1a) Since fedora.us will eventually become a major source of Fedora
Extras, fedora.us is to be considered canonical. fedora.us will no
longer exist as a project after the full merge with fedora.redhat.com.
2) In the kde-redhat example, since they are a 3rd party and not
canonical, it is possible that a future FC or FE upgrade will supercede
the kde-redhat package. For this reason it is important for kde-redhat
developers to BE INVOLVED in FC development so they are not caught off
guard. It is the 3rd party's responsibility to simultaneously release
updates to the 3rd party repository in order to avoid breakage or losing
features when the crippled packages overrides the kde-redhat package.
3) These guidelines of canonism may seem onerous, however this
encourages all 3rd party developers to contribute their packages to FC
and FE whenever possible in order to make the central authoritative body
strong. I would assert that the alliances of 3rd party repositories
that have tried to form in the recent past are not sustainable in the
long term, for the same controversial reasons that fedora.us rejected
cooperation with those entities earlier this year. More cooperation is
needed to build an entity and software base like Debian, what we want to
become. (?)

XXX

[Aurelien Bompard]

Hi

These guidelines seem fine, thanks for the work.

However, I have recently bumped into a package naming problem which doesn't
seem to be covered here. It's a program called K3B, a CD/DVD burning
frontend for KDE.
Here is their release numbers : 0.8 -> 0.9 -> 0.10
How should we set the RPM fields without using epochs in this type of
versionning ? Is is a case where epoch is necessary ?

Thanks

Aurelien

[Jesse Keating]

Post by Aurelien Bompard
Here is their release numbers : 0.8 -> 0.9 -> 0.10
How should we set the RPM fields without using epochs in this type of
versionning ? Is is a case where epoch is necessary ?

Does rpm actually fail on this? My understanding was that it takes the
number after the dot as a whole, where as "8" is less than "9" which is
less than "10".

[Bill Nottingham]

Jesse Keating (***@j2solutions.net) said:
Content-Description: signed data

Post by Jesse Keating

Post by Aurelien Bompard
Here is their release numbers : 0.8 -> 0.9 -> 0.10
How should we set the RPM fields without using epochs in this type of
versionning ? Is is a case where epoch is necessary ?

Does rpm actually fail on this? My understanding was that it takes the
number after the dot as a whole, where as "8" is less than "9" which is
less than "10".

Yes, rpm should handle that fine. It's not done as a float comparison.

Bill

[Aurelien Bompard]

Post by Bill Nottingham
Yes, rpm should handle that fine. It's not done as a float comparison.

Ok. On K3B's website, the developpers advise RPM packagers to use Epochs to
ensure that 0.10 will actually be considered higher as 0.9.
Thanks.

Aurelien

[Jesse Keating]

Post by Aurelien Bompard
Ok. On K3B's website, the developpers advise RPM packagers to use Epochs
to ensure that 0.10 will actually be considered higher as 0.9.
Thanks.

Sounds to me that the k3b developers don't know enough about rpm to make
such suggestions (;

Adding in epochs is evil, and should be avoided at all costs. I sincerely
hope that none of the 3'rd party packagers took said advice and added an
epoch to their k3b package...

- --
Jesse Keating RHCE MCSE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating

[Michael Schwendt]

Post by Aurelien Bompard
These guidelines seem fine, thanks for the work.
However, I have recently bumped into a package naming problem which doesn't
seem to be covered here. It's a program called K3B, a CD/DVD burning
frontend for KDE.
Here is their release numbers : 0.8 -> 0.9 -> 0.10
How should we set the RPM fields without using epochs in this type of
versionning ? Is is a case where epoch is necessary ?

Not a problem at all: 10 > 9 > 8

Btw, find k3b 0.10.2 and k3b i18n 0.10 src.rpms for Red Hat Linux 9
and Fedora Core here:

https://bugzilla.fedora.us/show_bug.cgi?id=885
https://bugzilla.fedora.us/show_bug.cgi?id=886

This may look a bit like an advertisement, but as with all the other
packages in the http://fedora.us/QA package queue, feedback is
always appreciated.

--

[Michael K. Johnson]

Post by Aurelien Bompard
However, I have recently bumped into a package naming problem which doesn't
seem to be covered here. It's a program called K3B, a CD/DVD burning
frontend for KDE.
Here is their release numbers : 0.8 -> 0.9 -> 0.10

That's no problem, RPM compares those correctly. That's normal version
numbering out there, and RPM has handled it since the beginning of (its)
recorded history.

Post by Aurelien Bompard
How should we set the RPM fields without using epochs in this type of
versionning ? Is is a case where epoch is necessary ?

Definitely do NOT use epoch here. I have heard that somewhere there is
a theory circulating that these cases require epoch, and they are like
practical examples of the apocryphal stories of philosophers debating
the number of teeth in a horse's mouth without once walking into the
barn to check!

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Owen Taylor]

Post by Michael K. Johnson

Post by Aurelien Bompard
How should we set the RPM fields without using epochs in this type of
versionning ? Is is a case where epoch is necessary ?

Definitely do NOT use epoch here. I have heard that somewhere there is
a theory circulating that these cases require epoch, and they are like
practical examples of the apocryphal stories of philosophers debating
the number of teeth in a horse's mouth without once walking into the
barn to check!

All experience with using Epoch leads to one conclusion:

Never, never, never, use Epoch.

It's better to use version numbers that have no relationship at all
to the upstream version than to use an Epoch. That is, if someone
can't be disuaded from calling their packages:

foo-alpha
foo-beta
foo-gamma
foo-delta

Use versions 1alpha 2beta 3gamma 4delta. If you didn't see delta
coming, then go with fedora1delta, fedora2epsilon, or something.

It may be ugly, but at least you don't have hidden version information
that people will use in some places and not others, resulting in
Requires: foo >= epsilon that do absolutely nothing.

Regards,
Owen

[Dag Wieers]

Post by Warren Togami
I would assert that the alliances of 3rd party repositories
that have tried to form in the recent past are not sustainable in the
long term, for the same controversial reasons that fedora.us rejected
cooperation with those entities earlier this year.

Rejected cooperation ? Excuse me ? When did that happen ;)

What controversial reasons ? It's funny, I remember you begging some 3rd
party packagers to join (the old) Fedora and the 3rd party packagers
you're refering to refused because of how (the old) Fedora was ran.

Let me say clearly that I consider the old Fedora and the new Fedora two
different things and I'm ready to work together with the new Fedora for
a lot of the packages I build (hopefully those that are endorsed by the
original developers, like distcc, nagios, avidemux, tvtime, conglomerate,
sodipodi, dovecot, amavisd-new, glabels, gringotts, rhythmbox, squidguard,
workrave, ... ).

Post by Warren Togami
More cooperation is needed to build an entity and software base like
Debian, what we want to become. (?)

Well, your false statement in the naming proposal doesn't really help and
has offended some people already.

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

[Axel Thimm]

I would assert that the alliances of 3rd party repositories that
have tried to form in the recent past are not sustainable in the
long term, for the same controversial reasons that fedora.us
rejected cooperation with those entities earlier this year.

I am sorry to hear that you still think you were doing the Right
Thing (TM).

When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide

o interrepository specifications (note "inter"!!!)
o merger proposals
o common infrastructure

In that sense a lot of input was provided for the versioning scheme.

Instead the project was driven towards a competitive repo, refusing to
add components that would make the specification more general, because
"there could only be one repository". You also managed to create the
largest repository compatibility problems ever (I just say epoch: 0),
that you were supposedly trying to avoid.

Many people left the fedora.us project because of that attitude. If
the project had been more open we would be much further today than we
are.

I am not speaking about or flaming fedora.us' community here, only
about the emerged leadership. Most fedora.us packagers have avoided
participating in Warren's crusade against other repos.

So please drop that attitude. You are damanging fedora.us,
fedora.redhat.com and repository intercooperation in general.

[Michael Schwendt]

Post by Axel Thimm

I would assert that the alliances of 3rd party repositories that
have tried to form in the recent past are not sustainable in the
long term, for the same controversial reasons that fedora.us
rejected cooperation with those entities earlier this year.

I am sorry to hear that you still think you were doing the Right
Thing (TM).
When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide
o interrepository specifications (note "inter"!!!)
o merger proposals
o common infrastructure
In that sense a lot of input was provided for the versioning scheme.
Instead the project was driven towards a competitive repo, refusing to
add components that would make the specification more general, because
"there could only be one repository". You also managed to create the
largest repository compatibility problems ever (I just say epoch: 0),
that you were supposedly trying to avoid.

While I'd like to stay out of this, because I've not been part of the
pre-fedora.us discussions, I skimmed over the list archives when I
subscribed to the list. May not count much, but it was -- and still is --
my impression that the maintainers of existing repos were not willing to
compromise. That made it really difficult for fedora.us to start.

Post by Axel Thimm
Many people left the fedora.us project because of that attitude. If
the project had been more open we would be much further today than we
are.

I find it very unfortunate to see that a lot of work is still duplicated.
If someone asked me whether I could explain why there are still several
independent repo maintainers who do their own rather closed thing, I would
admit that I don't know.

Fedora.us provides the infrastructure for collaborated packaging
efforts. Still, the reason why some repo maintainers don't team up, is not
the "explicit Epoch" or the package release versioning scheme. It's the
refusal to adhere to Fedora.us package submission and QA policies, because
it's easier to pipe out a new binary package instead of depending on other
people to review the src.rpm, and possibly having to fix broken build
requirements or unclean spec files before a package would be approved.

It would be really helpful if you, Axel, (or Dag or Matthias) would create
a complete list of points you dislike about current Fedora.us policies.
That would be interesting to understand what will be necessary to get you
to contribute to the Fedora Project rather than keeping alive your
independent repositories.

Post by Axel Thimm
I am not speaking about or flaming fedora.us' community here, only
about the emerged leadership. Most fedora.us packagers have avoided
participating in Warren's crusade against other repos.

"Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision
to serve the Red Hat Community with add-on packages from a single
repository which would make it easy for users to find additional software.

--

[tony]

Post by Michael Schwendt
"Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision
to serve the Red Hat Community with add-on packages from a single
repository which would make it easy for users to find additional software.

Now that Fedora is also a Redhat repository does this mean that mp3,
xine with decss, mplayer etc. etc. will be found there too? I think that
we will still need to go elsewhere to get the rpms that put the
finishing touch on any modern multimedia desktop OS.

Cheers

Tony Grant

[Stephan Windischmann]

Post by tony
Now that Fedora is also a Redhat repository does this mean that mp3,
xine with decss, mplayer etc. etc. will be found there too? I think that
we will still need to go elsewhere to get the rpms that put the
finishing touch on any modern multimedia desktop OS.

For now, we'll probably have to get the *-mp3, mplayer, anything with
decss, and other mutlimedia packages from seperate repositories because
of copyright and patent issues.

While this is an inconvenience, I understand this, because I don't want
the Fedora project to have to bother around with lawsuits regarding
them.

-windi

[Michael Schwendt]

Post by tony

Post by Michael Schwendt
"Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision
to serve the Red Hat Community with add-on packages from a single
repository which would make it easy for users to find additional software.

Now that Fedora is also a Redhat repository does this mean that mp3,
xine with decss, mplayer etc. etc. will be found there too? I think that
we will still need to go elsewhere to get the rpms that put the
finishing touch on any modern multimedia desktop OS.

Software with licensing and patenting issues is an exception, of course,
due to legal requirements of the Fedora Project.

Such software was removed from fedora.us and has been taken over by the
people at rpm.livna.org who aim at staying fully compatible with fedora.us
and who are working on setting up separate infrastructure, such as a
bugzilla system and build server.

--

[Jonathan C. Sitte]

Michael Schwendt wrote:
| Such software was removed from fedora.us and has been taken over by the
| people at rpm.livna.org who aim at staying fully compatible with fedora.us
| and who are working on setting up separate infrastructure, such as a
| bugzilla system and build server.

Is the livna peoples rpm scheme fixed now?
- --
Jonathan C. Sitte <***@staticnull.org>

[tony]

Post by Jonathan C. Sitte
| Such software was removed from fedora.us and has been taken over by the
| people at rpm.livna.org who aim at staying fully compatible with fedora.us
| and who are working on setting up separate infrastructure, such as a
| bugzilla system and build server.
Is the livna peoples rpm scheme fixed now?

I installed Xine, ogle and tried mplayer a couple of days ago with yum.

Xine and ogle had a couple of missing libraries that I had to go get
elsewhere and mplayer went into dependency loop hell and refused to
install.

I came away not very impressed.

Cheers

Tony Grant

[Michael Schwendt]

Post by tony

Post by Jonathan C. Sitte
Is the livna peoples rpm scheme fixed now?

I installed Xine, ogle and tried mplayer a couple of days ago with yum.
Xine and ogle had a couple of missing libraries that I had to go get
elsewhere

It is *important* to understand that rpm.livna.org is not a standalone
repository but depends on packages in Fedora Core _and_ Fedora.us. As
long as the fedora.us repository for Fedora Core 1 is not filled with
packages yet, you may need to live with the packages for Fedora Core 0.95
or even 0.94. Please give the build masters some time.

Post by tony
and mplayer went into dependency loop hell and refused to
install.

Do you have console output for that?

--

[tony]

Post by Michael Schwendt

Post by tony
and mplayer went into dependency loop hell and refused to
install.

Do you have console output for that?

# yum -c /etc/yum.conf install mplayer
Gathering header information file(s) from server(s)
Server: Red Hat Linux 9 - i386 - Base
Server: Fedora Compatible Packages (stable)
Server: Fedora Compatible Packages (testing)
Server: Fedora Compatible Packages (unstable)
Server: Red Hat Linux 9 - Updates
Finding updated packages

Resolving dependencies
.....identical dependency loop exceeded
package faad2 needs libsndfile.so.1(libsndfile.so.1.0) (not provided)

I have of course installed libsndfile

Cheers

Tony Grant

[Michael Schwendt]

Post by tony

Post by Michael Schwendt

Post by tony
and mplayer went into dependency loop hell and refused to
install.

Do you have console output for that?

# yum -c /etc/yum.conf install mplayer
Gathering header information file(s) from server(s)
Server: Red Hat Linux 9 - i386 - Base
Server: Fedora Compatible Packages (stable)
Server: Fedora Compatible Packages (testing)
Server: Fedora Compatible Packages (unstable)
Server: Red Hat Linux 9 - Updates
Finding updated packages
Resolving dependencies
.....identical dependency loop exceeded
package faad2 needs libsndfile.so.1(libsndfile.so.1.0) (not provided)
I have of course installed libsndfile

Hmmm, I don't see Fedora.us repositories in your server list.

"libsndfile" is a Fedora.us package. As pointed out earlier,
rpm.livna.org depends on Fedora.us packages.

But "faad2" does not depend on libsndfile.so.1. Raises the question what
faad2 and libsndfile packages you have installed and from where?

And why do you have Red Hat Linux 9 repositories in there?

--

[Jonathan C. Sitte]

Michael Schwendt wrote:
| Hmmm, I don't see Fedora.us repositories in your server list.
|
| "libsndfile" is a Fedora.us package. As pointed out earlier,
| rpm.livna.org depends on Fedora.us packages.
|
| But "faad2" does not depend on libsndfile.so.1. Raises the question what
| faad2 and libsndfile packages you have installed and from where?
|
| And why do you have Red Hat Linux 9 repositories in there?

Rejection of scheme? Does that mean his rpms are not using the scheme
that was agreed upon? If there was one that was agreed upon in the first
place...
- --
Jonathan C. Sitte <***@staticnull.org>

[Jonathan C. Sitte]

Jonathan C. Sitte wrote:
| Rejection of scheme? Does that mean his rpms are not using the scheme
| that was agreed upon? If there was one that was agreed upon in the first
| place...

The reason that I am asking is the fact that if he rejects the scheme
than I will possibly make my own rpms then. I thought it would be nice
to use his if the repository was using the correctly agreed scheme. It
is really easy to stop using that repos. Remove the rpm xmms-mp3 and
remove it from yum.conf. Heh. No skin off my back. This seems odd that
there is so much fragmentation with the rpm issue.
- --
Jonathan C. Sitte <***@staticnull.org>

[Michael Schwendt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| Rejection of scheme? Does that mean his rpms are not using the scheme
| that was agreed upon? If there was one that was agreed upon in the first
| place...
The reason that I am asking is the fact that if he rejects the scheme
than I will possibly make my own rpms then. I thought it would be nice
to use his if the repository was using the correctly agreed scheme. It
is really easy to stop using that repos. Remove the rpm xmms-mp3 and
remove it from yum.conf. Heh. No skin off my back. This seems odd that
there is so much fragmentation with the rpm issue.

Ehm, what are you talking of? I'm afraid I don't understand anything
of this. Please rephrase. "Rejection of scheme"? ...? Fragmentation?
Where do you see problems?

Practically, rpm.livna.org would not need to adhere to any package
versioning scheme at all. But its current 0.lvn.%{vepoch}.%{disttag}
scheme looks good and is beneficial.

--

[Jonathan C. Sitte]

Michael Schwendt wrote:
| Ehm, what are you talking of? I'm afraid I don't understand anything
| of this. Please rephrase. "Rejection of scheme"? ...? Fragmentation?
| Where do you see problems?
|
| Practically, rpm.livna.org would not need to adhere to any package
| versioning scheme at all. But its current 0.lvn.%{vepoch}.%{disttag}
| scheme looks good and is beneficial.

As long as it is safe then I am ok with it. I just want to make sure
people stay with the big picture here :). I boycott any repos that does
not follow the scheme that Fedora wants. It is good to know that it is
ok then :))
- --
Jonathan C. Sitte <***@staticnull.org>

[tony]

Post by Michael Schwendt
Hmmm, I don't see Fedora.us repositories in your server list.
"libsndfile" is a Fedora.us package. As pointed out earlier,
rpm.livna.org depends on Fedora.us packages.
But "faad2" does not depend on libsndfile.so.1. Raises the question what
faad2 and libsndfile packages you have installed and from where?
And why do you have Red Hat Linux 9 repositories in there?

OK I'm catching on now. This isn't very end user friendly...

I'll get all this straight now thanks. In any case xine works better
than mplayer on my machine...

Thanks again

Tony Grant

[Michael Schwendt]

Post by Jonathan C. Sitte
Is the livna peoples rpm scheme fixed now?

Seems so. At least the package release postfix looks sane:

0.lvn.%{release}.%{disttag}

That's fedora.us style with "fdr" replaced with "lvn".

--

[R P Herrold]

Post by Michael Schwendt
I find it very unfortunate to see that a lot of work is
still duplicated. If someone asked me whether I could
explain why there are still several independent repo
maintainers who do their own rather closed thing, I would
admit that I don't know.

A polite answer to that someone might be: Open Source
encourages freedom, experimentation and diversity -- Several
independendent packagers is the sign of a healthy Open Source
ecosystem.

A less 'politically correct' might mention fact that
'independent repo maintainers' are stubborn and independent,
see little reason to change, and cannot be _forced_ to change.

/me? I don't find it unfortunate at all that things have not
settled down. Looking beyond the initial Fedora project, lots
of interesting and practical work on RPM, SRPM mediated
package building, cvs checkout building, and build environment
has emerged in the last year. seth vidal's yum development,
Michael Redinger's rhel-rebuild, Greg Kurtzer cAos, several of
the independents' approaches, and the much awaited RH
unveiling of an echo of the Beehive (being item 3 of the RH
fedora annmouncement outline) all have or will help push the
art of RPM based package management.

Developers who are not working _just_ for monetary
compensation have have some other motivation to do research,
and implement testing harnesses to advance. We would not have
seen such fast progress without diversity and stubborn
independence.

------------

Post by Michael Schwendt
"Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision
to serve the Red Hat Community with add-on packages from a single
repository which would make it easy for users to find additional software.

Well, this is a less happy topic for me. The history is what
the history is, although we each bring our own
interpretations. Let's look through the record, and then
decide. The initial Fedora proposal which was at:
http://videl.ics.hawaii.edu/~warren/fedora.html
has gone dark; a copy is here:
http://www.owlriver.com/projects/packaging/fedora-manifesto-1.txt
but it did not 'start' as a 'single repository' proposal. It
arose in the clear success of FreshRPMs (indeed, was proposed
there), and followed other independent packaging efforts of
'add-ons'.

and later as to the 'crusade' aspect:
http://www.owlriver.com/projects/packaging/valediction.txt

[07:47:32] _warren- thomasvs: I understand the risk very well,
and I can only say that if Fedora has RH
updated packages as the result of extensive regression testing
that is something I would personally be
comfortable using. If you don't feel comfortable using it,
then please don't use it.

The former IRC archive linked at:
http://www.fedora.us/index-main.html
has gone dark, but the 'crusade' aspect arose from several
such statements on IRC and in the mailing list, which were
noted as dominance, control and process problems at that time
(as well as now).

http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000243.html
http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000244.html

(herrold responding to a post)

Post by Michael Schwendt
I hope that people do not see me as trying a "hostile takeover" of
FreshRPMS. I have great respect for Matthias and his good work with his
excellent packages. I am only pointing out these issues of co-existence.

[... ] But you have to expect criticism when you propose a
massive independent packager repository fork. There are not
that many of us, and after reflection, you have to know it
would leave a bad taste. The 'issue' of "co-existence" only
arises because of overlap. No overlap -- no issue.
...
As to the 'hostile takeover' matter, I certainly try to keep
perspective that we are only packaging software -- and that a
person who blindly relies on others, and automated maintenance
without understanding the issues is going to get wedged, from
time to time.
[...]
... so there are simply issues, benign and malicious, which
Fedora cannot solve. Accept it, get over it, and move on.
I'm gonna' keep packaging my way for my use in my repository;
until and unless the Fedora process gets documented, open, and
running, I'm not gonna sign any Fedora packages.
[...]

Anyway, back to [warren's] post, how else can one casually
read the comments at 03:34:52 and 03:34:55, other than as a
'there can be only one' Highlander ending... <grin>. If you
want essentially perfect, but exceedingly stale, you should
probably package only for Debian stable. <double grin>

[... The IRC transcript section:]
[03:34:52] <Warren> freshrpms and fedora cannot co-exist
[03:34:55] <Warren> in the long run

----------------------------------- quote ends

And to me, there was simply no other answer for my rhetorical
'how else can one casually read the comments' question,
because the 'single archive' and 'crusade' aspect of what his
vision of Fedora was clear, regardless of stated benign
intent. My solution: be stubborn and independent.

-- Russ Herrold

[Panu Matilainen]

Post by Axel Thimm

I would assert that the alliances of 3rd party repositories that
have tried to form in the recent past are not sustainable in the
long term, for the same controversial reasons that fedora.us
rejected cooperation with those entities earlier this year.

I am sorry to hear that you still think you were doing the Right
Thing (TM).
When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide
o interrepository specifications (note "inter"!!!)

Oh but that was NEVER the idea behind fedora.us. The idea was to create a
repository run by community of packagers, not a community of repositories
run by individuals. Why do you need 1000 different repositories if you can
stick the packages into one?

Post by Axel Thimm
o merger proposals
o common infrastructure

Merger was always up to the individual packagers with their repositories
to submit their packages to fedora.us QA, using the common infrastructure
provided by fedora.us. Some did, others didn't. As to why, I can only
agree with Michael: people didn't/don't want to change the way they do
things, have their packages go through rigorous (and slow) QA etc.

I find it kinda funny that people who refuse to co-operate within policies
and specifications created by the fedora.us community complain about
fedora.us not co-operating with them :-/

- Panu -

[Dag Wieers]

Post by Panu Matilainen
I find it kinda funny that people who refuse to co-operate within policies
and specifications created by the fedora.us community complain about
fedora.us not co-operating with them :-/

Most packagers were fed up even before decent policies and specifications
existed. Even before there was a common infrastructure or Fedora had any
packages committed. Whereas most 3rd party packagers already had more
packages then Fedora currently. This was a very different situation.

How those policies and specifications were made and the atitude of those
in charge towards existing repositories explain why a lot (most?) of
packagers left frustrated. And of course the fact that some of these
specifications made it impossible to be compatible didn't do any good
either.

I don't really understand how the project on one hand hopes/begs existing
packagers to submit their packages and on the other hand treats them
arrogantly and ignores their advice. I also don't understand why the
current negative critism towards the 3rd party packagers will get us any
closer and I was a bit of surprised that Warren had to bring that up
_again_.

I can only hope Red Hat's involvement can change the atmosphere a bit.

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

[Panu Matilainen]

Post by Dag Wieers

Post by Panu Matilainen
I find it kinda funny that people who refuse to co-operate within policies
and specifications created by the fedora.us community complain about
fedora.us not co-operating with them :-/

Most packagers were fed up even before decent policies and specifications
existed. Even before there was a common infrastructure or Fedora had any
packages committed. Whereas most 3rd party packagers already had more
packages then Fedora currently. This was a very different situation.
How those policies and specifications were made and the atitude of those
in charge towards existing repositories explain why a lot (most?) of
packagers left frustrated. And of course the fact that some of these
specifications made it impossible to be compatible didn't do any good
either.

Oh well, I'm speaking as someone who didn't have a repository of my own
and didn't want to create one so there was no change and thus no pain. I
think I do understand the pain involved for existing repositories and yes,
there certainly was some rough rides in early fedora.us discussions.

Post by Dag Wieers
I don't really understand how the project on one hand hopes/begs existing
packagers to submit their packages and on the other hand treats them
arrogantly and ignores their advice.
I also don't understand why the current negative critism towards the 3rd
party packagers will get us any closer and I was a bit of surprised that
Warren had to bring that up _again_.
I can only hope Red Hat's involvement can change the atmosphere a bit.

Oh I sure hope the new Fedora project will bring peace and love to all as
well, hostility wont get us anywhere.

- Panu -

[Nicolas Mailhot]

Post by Panu Matilainen

Post by Axel Thimm

I would assert that the alliances of 3rd party repositories that
have tried to form in the recent past are not sustainable in the
long term, for the same controversial reasons that fedora.us
rejected cooperation with those entities earlier this year.

I am sorry to hear that you still think you were doing the Right
Thing (TM).
When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide
o interrepository specifications (note "inter"!!!)

Oh but that was NEVER the idea behind fedora.us. The idea was to create a
repository run by community of packagers, not a community of repositories
run by individuals. Why do you need 1000 different repositories if you can
stick the packages into one?

An individual can have his own repo as a staging/testing area (a lot of
RH maintainers work like this), and there are repositories that will
*never* merge with fedora because they target more than one distribution
(ximian, jpackage...). Plus you can have several distros feeding from a
same core repository (I certainly hope aurora and yellowdog will use
fedora as source too)

Ah, and there are licensing issues too...

Even the kernel uses a multi-tree setup, and it's a *lot* more focused
than your average distribution.

So if you want an healthy ecosystem you need to recognise you're not
alone. Never will be. I don't give a damn about splendid isolation. I
want to be able to try Mdk bits, share stuff with RHEL, use experimental
rpms, etc If I thought otherwise I'd be using Debian now.

Cheers,

[Axel Thimm]

Post by Panu Matilainen

Post by Axel Thimm
o interrepository specifications (note "inter"!!!)

Oh but that was NEVER the idea behind fedora.us. The idea was to create a
repository run by community of packagers, not a community of repositories
run by individuals.

Of course it was, at least by the people that were finaly driven away ...

Post by Panu Matilainen
Why do you need 1000 different repositories if you can stick the
packages into one?

Others have given good explanations to why we need that.

Post by Panu Matilainen
I find it kinda funny that people who refuse to co-operate within policies
and specifications created by the fedora.us community complain about
fedora.us not co-operating with them :-/

Well, you should know that current fedora.us specs were also shaped by
the same people. Unfortunately vital components like interrepository
interaction were left out, and discussing these issues in March/April
wore all parties off, until many gave up on fedora.us.

The same question can be set the other way around: Why did fedora.us
had to reinvent the wheel once again?

[Michael K. Johnson]

Post by Axel Thimm

Post by Panu Matilainen
Oh but that was NEVER the idea behind fedora.us. The idea was to create a
repository run by community of packagers, not a community of repositories
run by individuals.

Of course it was, at least by the people that were finaly driven away ...

I'd like to state Red Hat's opinion on this matter, so I'll don my
"Technical Lead" hat for a moment.

It's VERY important to have a unified repository with shared packaging
standards where people can come for extra/alternative packages.

It's VERY important to enable ARBITRARY third-party repositories, for
software that for any of many reasons (level of testing, different
legal status in different countries, different licenses, maturity of
project, preference of packager) isn't in the unified repository.

These two goals are not in competition; they are separate goals (with
roughly equal weight) that Red Hat has for its participation in this
project.

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Axel Thimm]

Post by Michael Schwendt

Post by Warren Togami
I would assert that the alliances of 3rd party repositories
that have tried to form in the recent past are not sustainable
in the long term, for the same controversial reasons that
fedora.us rejected cooperation with those entities earlier
this year.

While I'd like to stay out of this, because I've not been part of
the pre-fedora.us discussions, I skimmed over the list archives when
I subscribed to the list. May not count much, but it was -- and
still is -- my impression that the maintainers of existing repos
were not willing to compromise. That made it really difficult for
fedora.us to start.

You have the wrong picture then. What compromises are you talking of?
Accepting fedora.us' non-comaptibility to their own repos?

Post by Michael Schwendt
I find it very unfortunate to see that a lot of work is still duplicated.
If someone asked me whether I could explain why there are still several
independent repo maintainers who do their own rather closed thing, I would
admit that I don't know.
Fedora.us provides the infrastructure for collaborated packaging
efforts. Still, the reason why some repo maintainers don't team up, is not
the "explicit Epoch" or the package release versioning scheme. It's the
refusal to adhere to Fedora.us package submission and QA policies, because
it's easier to pipe out a new binary package instead of depending on other
people to review the src.rpm, and possibly having to fix broken build
requirements or unclean spec files before a package would be approved.
As to why, I can only agree with Michael: people didn't/don't want
to change the way they do things, have their packages go through
rigorous (and slow) QA etc.

To answer to both of you: Personally I am fond of strict rules and
QA. I wouldn't mind a submission system similar to fedora's and hope
that the merger will polish it.

The problems are by far not technical. This would be a far too simple
explanation, and if I were the lazy type'a'guy, I wouldn't have wasted
so much time in getting the disttag's (and other specs) rolling.

[Michael Schwendt]

Post by Axel Thimm

Post by Michael Schwendt
As to why, I can only agree with Michael: people didn't/don't want
to change the way they do things, have their packages go through
rigorous (and slow) QA etc.

To answer to both of you: Personally I am fond of strict rules and
QA. I wouldn't mind a submission system similar to fedora's and hope
that the merger will polish it.
The problems are by far not technical. This would be a far too simple
explanation, and if I were the lazy type'a'guy, I wouldn't have wasted
so much time in getting the disttag's (and other specs) rolling.

Parting in blood is the wrong thing to do. Pushing alternative concepts
would be better. What is your list of disagreements with fedora.us'
policies? Have you posted a complete list before? Maybe you have a
pointer into the list archives?

With "not willing to compromise" I refer also to recent controversies,
such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking
for a redhat-release-10 package or changing the disttag from "rh9" (Red
Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate
suggestions. "rhfc1" is a hack, too. Or your package release versioning
scheme: Why don't your packages start at release 0 like fedora.us'
packages do? So when a package is included in Fedora Core or Fedora
Extras, by default it would override the lower release package in the
3rd party repository.

And one request, please don't take these mails so personal. You always
sound as if you're constantly fed up and take everything as insult. ;)

--

[Axel Thimm]

Pushing alternative concepts would be better. What is your list of
disagreements with fedora.us' policies? Have you posted a complete
list before? Maybe you have a pointer into the list archives?

Others and I tried to in March/April. fedora.us' archives is full of
that and the reaction.

With "not willing to compromise" I refer also to recent controversies,
such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking
for a redhat-release-10 package or changing the disttag from "rh9" (Red
Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate
suggestions. "rhfc1" is a hack, too.

No, it's not. I hope you will understand the issue and see that
Fernando delivered a magnificent solution compatible with rpm version
to Before Christ. Even one that I highly recommend for fedora.us.

Or your package release versioning scheme: Why don't your packages
start at release 0 like fedora.us' packages do? So when a package is
included in Fedora Core or Fedora Extras, by default it would
override the lower release package in the 3rd party repository.

Look closer, you are using my arguments from half a year ago that made
this part of fedora.us' specs. There are cases where this is
neccessary and these cases are reflected in the repo. This idiom is
also only then strictly neccessary when dealing with a closed vendor
(i.e. one that doesn't care about the outside world). That is said to
not be the case anymore.

And one request, please don't take these mails so personal. You always
sound as if you're constantly fed up and take everything as insult. ;)
Wrong. Please consider thinking about it a bit longer before you pipe
out your usual quick replies.

[Michael Schwendt]

Post by Axel Thimm

Pushing alternative concepts would be better. What is your list of
disagreements with fedora.us' policies? Have you posted a complete
list before? Maybe you have a pointer into the list archives?

Others and I tried to in March/April. fedora.us' archives is full of
that and the reaction.

It's a pain to find relevant postings in 1400 (or such) postings.
So, a list does not exist?

Post by Axel Thimm

With "not willing to compromise" I refer also to recent controversies,
such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking
for a redhat-release-10 package or changing the disttag from "rh9" (Red
Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate
suggestions. "rhfc1" is a hack, too.

No, it's not. I hope you will understand the issue and see that
Fernando delivered a magnificent solution compatible with rpm version
to Before Christ. Even one that I highly recommend for fedora.us.

Why "rhfc1" and not "vfc1"? Why "rh" == "Red Hat" in the disttag
when the distribution does not have the name "Red Hat Fedora Core"
but just "Fedora Core"?

Post by Axel Thimm

Or your package release versioning scheme: Why don't your packages
start at release 0 like fedora.us' packages do? So when a package is
included in Fedora Core or Fedora Extras, by default it would
override the lower release package in the 3rd party repository.

Look closer,

How close should that be? To realize that you decide on a case by case
basis whether to add the "0." prefix or not?

That prefix should be used consistently, because you cannot assume whether
a package will appear in Fedora Core (Extras, Alternatives, Development,
Testing, whatsoever), e.g. apt-0.5.5cnc7-36.rh9.1.at.src.rpm

[Fernando Pablo Lopez-Lezcano]

Post by Michael Schwendt

Post by Axel Thimm

Post by Michael Schwendt
With "not willing to compromise" I refer also to recent controversies,
such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking
for a redhat-release-10 package or changing the disttag from "rh9" (Red
Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate
suggestions. "rhfc1" is a hack, too.

No, it's not. I hope you will understand the issue and see that
Fernando delivered a magnificent solution

A bit of an exageration, to say the least. It is another option...

Post by Michael Schwendt

Post by Axel Thimm
compatible with rpm version
to Before Christ. Even one that I highly recommend for fedora.us.

Why "rhfc1" and not "vfc1"? Why "rh" == "Red Hat" in the disttag
when the distribution does not have the name "Red Hat Fedora Core"
but just "Fedora Core"?

It could also be zfc1, of course. "rhfc1" seemed to me a reasonable(*)
choice that solved the problem of upgradability _I_ have. Fedora Core is
not (yet?) an independent project, it is sponsored by RedHat, so
"rh"+"fc" felt right(*).

If I understand correctly the proper alternative as defined in the
naming guidelines would be to use a "1" (right?), but I really like the
readability of a string. This [may|will] not scale in the future, of
course, depending on how future distros in the same lineage are named.

-- Fernando

(*) of course this is subjective, somebody else [may|will] think that it
is a completely absurd choice.

[Jesse Keating]

Post by Axel Thimm
I am sorry to hear that you still think you were doing the Right
Thing (TM).
When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide

So it would seem that you're going to discount Warren's package naming
scheme, mearly because there is bad blood between him and some other
package repots? Great... thats nice.

Perhaps the rest of us should adopt Warren's proposal, and let the chips
fall where they may... sound familiar? What happened last time?
Individual repots that didn't work worth a crap with eachother, leading to
confused and helpless end users. Perfect way to support a project...

For cripes sake, drop the political crap and bad blood, review his proposal
and make some decent feedback on it instead of bickering about the past.

- --
Jesse Keating RHCE MCSE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating

[Nicolas Mailhot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Axel Thimm
I am sorry to hear that you still think you were doing the Right
Thing (TM).
When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide

So it would seem that you're going to discount Warren's package naming
scheme, mearly because there is bad blood between him and some other
package repots? Great... thats nice.

Nobody wrote so here. Quite the contrary - a lot of people are/were
expecting to do a new start with the new fedora and forget old history.
And that means working out something were multiple repositories can
coexist peacefully.
Answers like "there is no need for 3rd party repositories" do not help
at all.

[Panu Matilainen]

Post by Nicolas Mailhot

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Axel Thimm
I am sorry to hear that you still think you were doing the Right
Thing (TM).
When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide

So it would seem that you're going to discount Warren's package naming
scheme, mearly because there is bad blood between him and some other
package repots? Great... thats nice.

Nobody wrote so here. Quite the contrary - a lot of people are/were
expecting to do a new start with the new fedora and forget old history.
And that means working out something were multiple repositories can
coexist peacefully.
Answers like "there is no need for 3rd party repositories" do not help
at all.

I assume that's got to do with my "why you need 1000 repositories" comment
- sure, 3rd party repositories will always exist and are needed, things
like a special repos of kernel, jpackake etc for those special interest
groups are quite a different matter. What I meant by the "1000 repos"
comment is that it's just plain silly and waste of time that the same
pieces of software which basically everybody uses are
re-re-re-re-re-repackaged in various repositories just because people
can't agree on some policies.

And now I'm out of this political crap and back to doing something
hopefully remotely usefull :)

- Panu -

[Axel Thimm]

Post by Jesse Keating

I would assert that the alliances of 3rd party repositories that
have tried to form in the recent past are not sustainable in the
long term, for the same controversial reasons that fedora.us
rejected cooperation with those entities earlier this year.
I am sorry to hear that you still think you were doing the Right
Thing (TM).
When Fedora (US) was being formed it attracted many repo maintainers
like freshrpms, newrpms, dag and many others including myself. They
hoped for a coordination institution within fedora, which should
provide

So it would seem that you're going to discount Warren's package
naming scheme, mearly because there is bad blood between him and
some other package repots? Great... thats nice.

Were did you read any reference on his naming scheme above to deduce
your statements?

Post by Jesse Keating
Perhaps the rest of us should adopt Warren's proposal, and let the
chips fall where they may... sound familiar? What happened last
time? Individual repots that didn't work worth a crap with
eachother, leading to confused and helpless end users. Perfect way
to support a project...
For cripes sake, drop the political crap and bad blood, review his
proposal and make some decent feedback on it instead of bickering
about the past.

To see it soberly: The strategical question is whether to have
multiple repos or only one.

People with their own repo tend not to prefer solutions allowing
repository mixing. This was and is out of Warren's scope and is fine
that way, and is is fine that he explicitly states so. It is also fine
to believe otherwise.

But you cannot bring the two concepts together.

[Dag Wieers]

Post by Jesse Keating
So it would seem that you're going to discount Warren's package naming
scheme, mearly because there is bad blood between him and some other
package repots? Great... thats nice.

Your insinuating things. Warren's proposal contains items that 3rd party
repositories have also contributed to, but it also lacks stuff we've
discussed before. This thread is about a hostile comment in the proposal.
A diplomatic hitch.

Post by Jesse Keating
For cripes sake, drop the political crap and bad blood, review his proposal
and make some decent feedback on it instead of bickering about the past.

Well, I think you can summarize this thread as follows: please remove the
hostile comment about 3rd party repositories and the twisted view of
history ;) If it wasn't in there, this thread wouldn't have existed in the
first place.

And I've already submitted some other feedback about the content of the
proposal. Did you ?

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

[Jesse Keating]

Post by Dag Wieers
Well, I think you can summarize this thread as follows: please remove
the hostile comment about 3rd party repositories and the twisted view of
history ;) If it wasn't in there, this thread wouldn't have existed in
the first place.

That i can live with. If the comment is removed, will this tread die?
please?

Post by Dag Wieers
And I've already submitted some other feedback about the content of the
proposal. Did you ?

I've discussed some of the points with Warren on IRC, but I'm still trying
to sort through this mess that has spread across 3 different lists.

- --
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating

[Warren Togami]

Post by Jesse Keating

Post by Dag Wieers
Well, I think you can summarize this thread as follows: please remove
the hostile comment about 3rd party repositories and the twisted view of
history ;) If it wasn't in there, this thread wouldn't have existed in
the first place.

That i can live with. If the comment is removed, will this tread die?
please?

I have to admit it was the wrong place to put that comment and it was
worded in a poor way. Again I shouldn't be posting things at 4AM. At
the time I wanted discussion on all of the sections marked with "XXX",
which I still do. Don't worry, the actual document wont contain
anything about that.

Post by Jesse Keating

Post by Dag Wieers
And I've already submitted some other feedback about the content of the
proposal. Did you ?

I've discussed some of the points with Warren on IRC, but I'm still trying
to sort through this mess that has spread across 3 different lists.

I would encourage everyone not to cross-post anymore, it further
confuses issues.

Warren

[Warren Togami]

http://www.fedora.us/wiki/RepositoryMixingProblems

Many months ago I wrote this, and my stance has not changed. The top 3
bullets are my arguments in this topic. The inevitable instances where
your 3rd party repositories were inconsistent with each other and thus
breaking consistency have happened several times since.

The crux of the matter ...
Cooperation among an arbitrary mix of repositories controlled by
_individuals_ in a closed nature is inherently problematic. It is
however fine if you don't mind it being broken sometimes, and almost
zero peer review of the sources going into the packages.

After all these months we are still arguing over the same tired points
and my position has still not changed. I will say nothing more on this
matter.

Granted this page never suggested a viable solution to license
problematic packages which cannot be contained at fedora.us. I will
then give you the solution now: The same type of group needs to form
their own collaborative repository project outside of the USA for
non-American use where it is legal. This theoretical project needs
their own Bugzilla, QA process, mirrors and such. Unfortunately due to
my country's laws it would be unlawful for me to use work on or use
software from such a theoretical project.

Warren

[Jonathan C. Sitte]

Warren Togami wrote:
| After all these months we are still arguing over the same tired points
| and my position has still not changed. I will say nothing more on this
| matter.

I agree with you completely on this matter as well. I do not know why
this is even an issue. I thought the whole idea of the project was for
the people of redhat and the community to work as a team. I have been
telling this to people on the fedora-list as well. They don't seem to
care much on irc.freenode.net #fedora. I don't even bother there. All I
get is go to this repos or that to get this or that. I ask them. Is the
repos a fedora standard. They seem to not care. Just a thought. ;)
- --
Jonathan C. Sitte <***@staticnull.org>

[Dag Wieers]

Post by Warren Togami
Should we actively discourage packages that *appear* to be plugin,
add-on or theme packages but are actually completely independent? One
example that has caught me off guard lately was Dag's mozilla-firebird
package. While Dag published mozilla-firebird, fedora.us decided
against a name change from MozillaFirebird to mozilla-firebird for these
1) No reason to change.
2) Mozilla branding strategy document said the name was changing "soon"
anyway, (which still hasn't happened.)
3) mozilla-firebird is within the long implicitly understood and
fedora.us codified standard of being a component or add-on to "mozilla",
which is clearly wrong in this case.
#2 and #3 were the strongest arguments in my opinion.
I can't think of any other past examples off the top of my head, but I
really want to avoid these kinds of instances in the future if
possible. Please express your opinions.
XXX

You say it *appears* to be a plugin, and I think that's the problem. There
is already a multitude of packages that start off with the same base and
are not plugins or add-ons per se. eg.

amanda vs. amanda-client (one can be used without the other)
bind vs. bind-utils
compat-*
control-center vs. control-panel (no connection)
desktop-backgrounds-basic vs. desktop-file-utils
...

They all appear to be plugins (if you only think of that rule) yet we
don't urge to change. So #3 is not an exclusive rule, just a guideline for
packagers. It never said that it only could be plugins though.

#1 doesn't make a difference if you start off adopting a name. I never
adopted 'MozillaFirebird' for several reasons (mixed casing is one of
them, Debian and Mandrake's decision is another one). If Fedora started
off adopting mozilla-firebird, there was no need to change the name
either.

And the branding doesn't dictate to use mixed casing or the elimination
of the standard seperator '-'. Only that it is called 'mozilla firebird'
and not just 'firebird'. Everybody knows why ;) So #2 doesn't really
convince me. I had to call it mozilla-firebird, without casing and with a
proper seperator.


The only reason to adopt 'MozillaFirebird' is because the tarball is
called that way. And although it is important to consider that name first,
there are a lot of other considerations to be made, like mixed casing,
what other distro's do, is it a plugin/add-on, is it a library for
python/perl/php, what is the pragmatic thing to do.


If you want to avoid this kind of clashes, it would be better to not allow
upper-case in package-names and to forbid other seperators than '-' (not _
or '').

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

[Michael Schwendt]

Post by Warren Togami
B. Version
C. Release Tag
3. Non-Numeric Version to Release

The post-release non-numeric versioning scheme at the bottom of these two
section needs to be dropped when it conflicts with Red Hat's scheme
(e.g. the perl-DateManip-5.42a example).

--

[Pozsar Balazs]

Post by Warren Togami
C-3. Non-Numeric Version to Release
-----------------------------------
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
versioned packages can be problematic so they must be treated with care.
These are cases where the upstream version has letters rather than
simple numbers in their version. Often they have tags like alpha, beta,
rc, or letters like a and b denoting that it is a version before or
after the number. Read section B to understand why we cannot simply put
these letters into the version tag.
0.%{X}.%{alphatag}
%{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.

[...]

PLEASE, take a look at dpkg's and apt-get's way of handling pre-release
versions, I really do think that should be used in rpm-based distros
too.
The idea is to introduce a character, namely '~' (tilde), which is
sorted specially: in comparison it comes before anything else.

This way, you can get ordering like this:

1.0~alpha1 < 1.0~alpha2 < 1.0~beta < 1.0 < 1.0a < 1.0b
1.0~pre1 < 1.0~rc1 < 1.0 < 1.0.1 < 1.0.2
... and so on.

Hope you got the point.

I know it should be implemented in rpm, and this is not a trivial move,
but please do think about it. It will make all these
pre-release-versioning nightmares go away.


bye,

[Warren Togami]

Post by Pozsar Balazs
PLEASE, take a look at dpkg's and apt-get's way of handling pre-release
versions, I really do think that should be used in rpm-based distros
too.
The idea is to introduce a character, namely '~' (tilde), which is
sorted specially: in comparison it comes before anything else.
1.0~alpha1 < 1.0~alpha2 < 1.0~beta < 1.0 < 1.0a < 1.0b
1.0~pre1 < 1.0~rc1 < 1.0 < 1.0.1 < 1.0.2
... and so on.
Hope you got the point.
I know it should be implemented in rpm, and this is not a trivial move,
but please do think about it. It will make all these
pre-release-versioning nightmares go away.

Interesting concept. This is the first time I heard of this. It would
take a serious amount of analysis to figure out if this can be
implemented in rpm in a way that wont break backward compatibility.
There is also the question of if we *want* to do this or not. Much
discussion is needed. In any case it would take a long time to analyze
if we want to implement this in rpm and all related tools or not. I
currently have no opinion on this matter because I don't know enough
about it.

In the mean time this package naming scheme describes how to properly
avoid packaging problems in the rpm of today.

Warren

[Mike A. Harris]

Post by Warren Togami

Post by Pozsar Balazs
PLEASE, take a look at dpkg's and apt-get's way of handling pre-release
versions, I really do think that should be used in rpm-based distros
too.
The idea is to introduce a character, namely '~' (tilde), which is
sorted specially: in comparison it comes before anything else.
1.0~alpha1 < 1.0~alpha2 < 1.0~beta < 1.0 < 1.0a < 1.0b
1.0~pre1 < 1.0~rc1 < 1.0 < 1.0.1 < 1.0.2
... and so on.
Hope you got the point.
I know it should be implemented in rpm, and this is not a trivial move,
but please do think about it. It will make all these
pre-release-versioning nightmares go away.

Interesting concept. This is the first time I heard of this. It would
take a serious amount of analysis to figure out if this can be
implemented in rpm in a way that wont break backward compatibility.
There is also the question of if we *want* to do this or not. Much
discussion is needed. In any case it would take a long time to analyze
if we want to implement this in rpm and all related tools or not. I
currently have no opinion on this matter because I don't know enough
about it.
In the mean time this package naming scheme describes how to properly
avoid packaging problems in the rpm of today.

One problem is that the word "pre", or "rc" or others are not
used consistently between software projects.

Some use "pre" like:

Prerelease: 2.7.95pre1 (prerelease of version 2.8, or perhaps 2.7.96)
Release: 2.8

Others use "pre" like:

Prerelease: 2.8pre1 (Prerelease of version 2.8)
Release: 2.8

It's possible that one project does it like above, and another
does it like:

Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)

Both types of versioning are out there. There is no way of
knowing wether the "pre" part is newer or older based solely upon
alphanumeric comparison, because different projects use the
keyword differently. The only way is by human interpretation.
As such, having the software consistently use one single
interpretation is the best solution, as you know 50% of the
projects out there will work without thinking about it. Then
it's only the other 50% that need manual developer attention, and
that can't be voided as it isn't possible to know which of the
two interpretations is intended via software alone.

[Pozsar Balazs]

Post by Mike A. Harris
One problem is that the word "pre", or "rc" or others are not
used consistently between software projects.
Prerelease: 2.7.95pre1 (prerelease of version 2.8, or perhaps 2.7.96)
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.8)
Release: 2.8

These two are obviously not a problem.

Post by Mike A. Harris
It's possible that one project does it like above, and another
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)

Could you give me an example of this? (Imho this scheme is
braindamaged...) I've never seen any projects with this versioning.

Anyway, 2.8 < 2.8pre1 is true, so these are ordered correctly.
Though if a version "2.8q" was released (as a bug-fix release for the
stable 2.8 branch) 2.8q and 2.8pre1 would be ordered incorrently, but this
is really a problem with the author, not the algorithm.


Introducing '~' would solve problems, and the only con I see is backward
compatibility. Hope it can worked out :)

[Mike A. Harris]

Post by Pozsar Balazs

Post by Mike A. Harris
It's possible that one project does it like above, and another
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)

Could you give me an example of this? (Imho this scheme is
braindamaged...) I've never seen any projects with this versioning.

The Linux kernel. kernel-2.6.0testN

There are tonnes of projects that do this however, so I'm kindof
surprised if you've never seen any. Do you use the GNU hurd
kernel perhaps? ;o)

[Peter Backlund]

Post by Mike A. Harris

Post by Pozsar Balazs

Post by Mike A. Harris
It's possible that one project does it like above, and another
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)

Could you give me an example of this? (Imho this scheme is
braindamaged...) I've never seen any projects with this versioning.

The Linux kernel. kernel-2.6.0testN
There are tonnes of projects that do this however, so I'm kindof
surprised if you've never seen any. Do you use the GNU hurd
kernel perhaps? ;o)

Not the same thing, this scenario was about using "2.6.0test1" as
version number for something leading up to 2.7.0, which I've never seen
either. The kernel method or using 2.6.0testX leading up to 2.6.0 is
however very common.

/Peter

[Michael Schwendt]

Post by Mike A. Harris

Post by Pozsar Balazs

Post by Mike A. Harris
It's possible that one project does it like above, and another
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)

Could you give me an example of this? (Imho this scheme is
braindamaged...) I've never seen any projects with this versioning.

The Linux kernel. kernel-2.6.0testN

That would become: 2.6.0~testN < 2.6.0

--

[Alexandre Oliva]

Post by Pozsar Balazs

Post by Mike A. Harris
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)

Could you give me an example of this? (Imho this scheme is
braindamaged...) I've never seen any projects with this versioning.

Autotools (autoconf, automake and libtool) have agreed to use such a
scheme quite a while ago, and one of the reasons behind such a scheme
was exactly to accomodate RPM's versioning rules.

Say libtool 1.4.2a was a CVS snapshot out of the 1.4 branch right
after release 1.4.2; 1.4.2b was a semi-stable released snapshot
leading towards 1.4.3. 1.4.2c was a CVS snapshot after 1.4.2b, etc,
with `odd' letters being used for CVS snapshots and `even' letters
used for tarballs released out of alpha.gnu.org.

Meanwhile, mainline was be versioned 1.4a, meaning it targeted release
1.5. 1.4b was a semi-stable released snapshot, 1.4c was again a CVS
snapshot.

At some points right after cutting a branch, we'd have something like
1.4.0a, to distinguish it from 1.4a, and to make it clear it's leading
towards 1.4.1.

I no longer remember the exact details, so I may have got something
wrong, but the scheme actually makes some sense, given the design
constraints.

[Pozsar Balazs]

Post by Alexandre Oliva

Post by Pozsar Balazs

Post by Mike A. Harris
Release: 2.8
Prerelease: 2.8pre1 (Prerelease of version 2.9)

Could you give me an example of this? (Imho this scheme is
braindamaged...) I've never seen any projects with this versioning.

Autotools (autoconf, automake and libtool) have agreed to use such a
scheme quite a while ago, and one of the reasons behind such a scheme
was exactly to accomodate RPM's versioning rules.

[...]

Okay, I understand your example. I was focusing on 'pre', which I still
think is not used this way, but other postfixes, most commonly
'a', 'b', 'c'... are do used.

But, as you also mention, these schemes can be handled long ago easily, so
they do not need fixing, and they do not need the usage of the proposed
'~' special tag.

You might misunderstood me: the purpose of the '~' marking is _NOT_ to use
it every time when a version number is kind of 'pre', but to use it when
you want to express ordering impossible (without 'hacks') without it.

So 1.4.0 < 1.4.0a < 1.4.0b < 1.4.1 is perfectly ordered now and ever,
but if you want to order '1.4.0', '1.4.1-pre1' and '1.4.1' you either have
to use tricks, or simply use '~':
1.4.0 < 1.4.1~pre1 < 1.4.1


ps: sorry if this is overexplanation, shoot me :)