Core Packages in Violation of the Fedora Naming Guidelines

[Mike A. Harris]

Tom 'spot' Callaway wrote:
>>  > xorg-x11-xkbdata-1.0.1-8.xkbc0.8.0.src.rpm
> 
> Fixed: xorg-x11-xkbdata-1.0.1-9.src.rpm
> Fixed (with dist tag): xorg-x11-xkbdata-1.0.1-9.fc6.src.rpm

The xorg-x11-xkbdata package originally contained X.Org's xkbdata
package, version 1.0.1.  However, prior to the release of FC5,
after much debate and consideration, the decision was made to
switch to the "xkeyboard-config" project's xkbdata, as the X.Org
data was obsolete and unmaintained.  Unfortunately this came late
in the FC5 devel cycle, and we were unable to get a new package
name included in the OS as "xkeyboard-config".

Since the contents of "xorg-x11-xkbdata-1.0.1" was now actually
"xkeyboard-config-0.8" and we were unable to call it that, I
encoded the real package name into the Release field concisely,
as it was important to know what release of xkeyboard-config
was actually shipping by looking at NVR.  This was only intended
as an ugly hack workaround to the problem of being unable to
rename the package at that time.

Now, in FC6 development that restriction is no longer in place,
and so the package is now called "xkeyboard-config-0.8" which
obsoletes the former xorg based package.


The Intel i810 driver in rawhide contains "modeset<date>" which
ajax added to indicate that this is not the standard X.Org i810
driver, but is instead the developmental 'modeset' branch that
Eric Anholt is working on.  It is important to us to be able
to distinguish wether people are using the traditional i810
driver, or the modeset one in bug reports.

Having said that, none of these workarounds are intended to be
present in the final builds for FC6.  By the time FC6 ships, it
is intended that the 'modeset' driver will become the official
i810 driver, merged into CVS head upstream, however that has
not yet happened.

Perhaps the release naming rules could be extended a bit, such
as permitting a string to be prefixed or suffixed to indicate
the branch of CVS, or some other arbitrary identifier.

"1.fc6.20060503git.modeset"?

An alternative would be a separate package name instead, and
shipping both drivers:  xorg-x11-drv-i810 and xorg-x11-drv-i810modeset,
however we want people exclusively testing the modeset driver now.
Some are using rawhide drivers in FC5, and mixing and matching
modular X packages.  When they provide their RPM package NVRs,
it is obvious right now that they're using the modeset driver.

We're (our team) open minded though, feedback appreciated.


>>  > Bad CVS naming (cvs should be at end of date, not beginning)
>>  > ============================================================
> 
> CVS falls under the snapshot rules. To handle snapshots, first identify,
> is this a pre-release, or a post-release?
> 
>>> krb5-auth-dialog-0.6.cvs20060212-3.src.rpm
> 
> I'll assume this is a pre-release, and that 0.6 has yet to be released.
> In this case, this package should be fixed as:
> 
> Fixed: krb5-auth-dialog-0.6-0.7.20060212cvs.src.rpm
> Fixed (with dist tag): krb5-auth-dialog-0.6-0.7.20060212cvs.fc6.src.rpm
> 
> If you need to patch a pre-release or put in a new cvs checkout, you
> bump the non-zero integer in the Release field, but LEAVE THE ZERO AS
> ZERO. This is important.
> 
> Unfortunately, this is a case where conforming to the guidelines will
> require a one-time epoch bump in the new package, since rpm thinks that
> 0.6.cvs20060212-3 is newer than 0.6.

I've told some people not to do that in their packages, and ended
up in a heated debate over it that I found to be not worthwhile so
dropped the discussion thinking "they'll find out the hard way
later".  Perhaps we could have the buildsystem encode all of these
"rules" into software which denies your ability to build the package
unless the rules are followed.  That would be a bit of a PITA for some
corner cases, but save headaches in the long run from history repeating
itself, and also save having to re-discuss/re-debate it every time
someone else hits a problem and isn't aware of all the rules and the
reason they exist.

I'm all for computer software forcing humans to not have the opportunity
to introduce human err into problems that have had solutions developed
and documented. Documentation alone doesn't prevent humans from making
errors, but computer software that sits in between and doesn't permit
the errors does.  ;o)

Just a thought anyway...

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.