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

[Ralf Corsepius]

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", I didn't. Conversely, I am
talking about "compatible replacement packages" and "add-ons".

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

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

This could be handled by examples on a case by case basis.

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

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

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

> But let's try to add a comment. Maybe that explains it already:
> 
> In my view, packagers need no stinking dist tag,
My view is opposite: Not having a mandatory dist tag is a design flaw.

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

Ralf