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