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

[Michael Schwendt]

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". The guidelines cannot fix that.
 
> > 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. 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.

Btw, "simple and clear" is so vague, it says nothing actually.

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

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?  I don't think so. 

But only then the fun starts, since you arrive in upgrade hell or with a
conflict of some sort. FC|FE packages upgrade 3rd party packages or vice
versa, packager picked a different release or snapshot, etc. And if the
3rd party packager continues supplying upgrades which replace stuff in
FC|FE, who's to blame?  Even if a 3rd party package bumped the Epoch in
order to upgrade a FC|FE package _always_, it would continue being a
conflict. 

And it is so easy to create conflicts despite adhering to the
guidelines. The guidelines don't say which upstream version to put into
package "libfoo", which other upstream release to put into package
"libfoo20", and which release to put into "compat-foo". The guidelines
won't fix that by becoming more "simple". The opposite won't be true
either. The longer, the more detailed and more specific the guidelines
get, the fewer packagers will be comfortable with them and every tiny
detail. Even a trivial package would create a conflict if at the time it
enters FC|FE it exists with a higher %{release} in an arbitrary 3rd party
repository.

> > > > > xscreensaver-5.00-7.1.fc6
> > > > 
> > > > This is bad. 7.1.fc6 is newer than 7.fc7. In general, '1' > 'f'.
> > > 
> > > > > Q: Are N and M supposed to be <int>?
> > > > 
> > > > Yes. _But_ it's only N{?dist} and 0.N{?dist} for pre-releases.
> > > C.f. above. IMO, a defect of the guidelines and to be reconsider.
> > > 
> > > Let's keep things simple, instead.
> > 
> > Things would be simplified a lot if we didn't limit our own flexibilities
> > in choosing package versions and if 3rd party packagers would not create
> > conflicting packages.
>
> How do you think are developers supposed to package packages?

Please rephrase. I don't understand the question.

But let's try to add a comment. Maybe that explains it already:

In my view, packagers need no stinking dist tag, 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.