[Fedora-packaging] Re: [Bug 192912] Review Request: paps

[Michael Schwendt]

On Tue, 20 Jun 2006 06:08:51 +0200, Ralf Corsepius wrote:

> On Sun, 2006-06-18 at 00:26 +0200, Michael Schwendt wrote:
> > On Sat, 17 Jun 2006 22:06:49 +0200, Ralf Corsepius wrote:
> > 
> > > > Why can't they just use the same versioning scheme?
> > > 
> > > > Why and when would they supply a package, which is in Core or Extras
> > > > already, with an incompatible version than what either is in Core and
> > > > Extras or will be in Core or Extras later
> > >
> > > E.g. because 
> > > * legal restrictions prohibits Core or Extras to ship them
> > > * developers use repos to ship upstream snapshots for testing.
> > > * local demands require packages neither FC nor FE ships.
> > > * packages are stuck in FE review.
> > > etc. pp.
> > 
> > You failed to answer why they would supply a package with "an incompatible
> > version".
> YOU were talking about "incompatible",

Because that's what many 3rd party packagers do. They provide packages
which either are incompatible one way or the other or will be incompatible
with future packages in FC+FE.

> I didn't. Conversely, I am
> talking about "compatible replacement packages" and "add-ons".

Replacement packages are inherently incompatible. Not only do they add
something to the package namespace, they also take away something.

> > > > It is extremely inconvienient and tiresome for anyone, who works on
> > > > packaging guidelines, to consider packaging scenarios for packagers who
> > > > don't adhere to the same guidelines.
> > > 3rd parties would consider FE's guidelines, if they were simple and
> > > clear.
> > > 
> > > Face it: So far they are not.
> > 
> > And won't ever be.
> You can. It's only matter of conventions.

It's called Utopia.

guidelines are too simple => too much room for different interpretations

guidelines are too complex => too much familiarity needed, too much time
needed to study each and every detail in order to get everything right in
a predictable manner

> >  Just take a look at the package naming guidelines
> > and examples like "muse vs. emacs-muse vs. ...". The guidelines will
> > never be bullet-proof in such a way that 3rd party package suppliers
> > can do whatever they want without needing to track changes in FC+FE.
>
> True, but .. this is the "Name" in NEVR.

qed ;)
 
> This could be handled by examples on a case by case basis.

Then get 3rd party packagers to _ask_ the Fedora Packaging Committee
prior to introducing new packages into the Fedora package universa.

> > > I hereby formally ask YOU (MS) to write them up and give clear
> > > confirmative _directions_ of how FE 3rd party packagers shall chose
> > > NEVRs that are guaranteed not to conflict with FE nor FC.
> > > 
> > > I clearly doubt you'll be able to do so.
> > 
> > With all due respect, this is silly, Ralf. It is trivial to supply
> > packages which extend Core+Extras in a safe way _until_ the same packaged
> > software is included in Core or Extras.
>
> How? Explain, elaborate ... that's what I am asking.

Do you ignore the "_until_" deliberately because you're in a mood to
argue? Everyone can take a new libfoozooboo and a corresponding
application, create rpms for it and offer it as an clean add-on to
FC+FE without overwriting or replacing any packages.

Where's the problem? The problems start when a Fedora contributor packages
the same or a different version of this software for FC|FE.

What problems? Too many to cover them in detail, not limited to: Different
N in NEVR (some 3rd party packagers just love the SONAME major version in
N game), too high EVR, too high VR, too high R, upgrade race back and
forth between Fedora and 3rd party repo, files in sub-packages vs. files
in main package, different feature set, broken libtool archives included
or not, ... moan, gah!

> > While the 3rd party packager can make sure any chosen NEVR is compatible
> > with existing packages in FC|FE, are Fedora Project package developers
> > obliged to know about all packages which may be "out in the wild" at the
> > time they add a package to FC|FE?
>
> With a little good will, reflected into conventions, they could.

The more often you claim this, the more likely it becomes that you will
need to submit a proposal. Accept the offer to join the Fedora Packaging
Committee and work on this.

> I wanted you to clearly describe in detail, how packagers (Core, Extra
> and 3rd party) are supposed to chose "Version-Release", which is
> guaranteed to be safe. 

1) Core and Extras packagers monitor eachother. That's a MUST for any
package which moves from Core to Extras or vice versa. Else a rushed
upgrade in Extras for an older dist might be newer than the package
in a more recent release of Core (or vice versa). Has happened before,
will happen again.

2) The packaging guidelines and versioning scheme are publicly available
for everyone to take a look at and adhere to.

3) As a 3rd party packager, DO NOT set Epoch, not even if any contributed
upstream package has Epoch > 0.

4) You need not choose a VR which increases the risk of being newer than
a future package in FC|FE. Avoid the mess with non-numerical pieces in V.

5) 3rd party packagers NEED to decide whether to upgrade FC+FE always
(Epoch can be used as well as a sufficiently high R, e.g. R=1000) or
whether to supply pre-release types of packages, which are upgraded
by FC|FE as soon as the package is included in FC|FE (keep the
most-significant part of R = 0.0%{?dist}.X and increment only the
least-significant part X).

> > In my view, packagers need no stinking dist tag,
>
> My view is opposite: Not having a mandatory dist tag is a design flaw.

Because of what?

> >  and they only must ensure
> > that their most recent package release is seen as an upgrade of every
> > older package release. That is, when Joe User on up-to-date FC4+FE4
> > inserts the brand-new set of FC6+FE6 CDs, which he ordered at his popular
> > online shop, all packages on the CDs are sufficiently "newer than" his
> > up-to-date FC4 installation.
>
> If Release was chosen N%{dist}.M (N, M .. int) this would happen
> automatically and the user would not have to care about anything.

No. Think twice. It fails when a new V of an update for an old dist
becomes higher than V for a stock package of a new dist. In that case,
only Epoch=dist would be the way out.

  FC4: foo-1.0-4.1
  FC4 updates: 1.0-4.2, 1.0-4.3, ..., 1.2-4.1 (ooops! newer than stock FC5)

  FC5: foo-1.0-5.2
  FC5 updates: 1.0-5.3, 1.0-5.4, ... 1.2-5.1 (!)

You could also include %{?dist} and move it to the very left, creating fun
for 3rd party packagers who don't use the same dist tags.

Nothing new. Just fails due to V bumps, and due to E being used by some
packages already for purposes other than E=dist.

A "Distribution Epoch" in the RPM header would be the cure. ;)