Re: RFC: Fedora revamp proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5. 3. 2013 at 18:50:45, Colin Walters wrote:
> On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote:
> > We don't ship in a way that easily allows this though, now. Admittedly,
> > this is due to the sheer *amount* of stuff involved in just maintaining
> > single versions of things, and how much that would jump if we started
> > having multiple versions available all the time.
>
> To be clear, I am not suggesting multiple versions.  The suggestion is
> that the old version of mesa overrides the new version and the tests
> (and users) get it.

I think what Bill meant was to keep older versions of package in repos, as
Debian distros do. It's not necessary to keep them locally. Having multiple
versions in repos would solve the issue, as you would always have the option
to install any of the older ones.

However your proposal for old version explicitly overriding new version isn't
just a problem of tooling. It's a problem of understanding the entire package
release timeline. If you want an old package to override the new package, you
will of course need to somehow specify that the new version of the package
obsoletes all the old ones except the "reversion" while the new-new version
obsoletes all of them, including the reversion. Diificult to comprehend? Now
imagine implementing and actually using it as maintainer ;-)

Also, you still have to put this information into the old package somehow,
i.e. rebuild it. If you don't do that, you will miss a piece of the timeline.

Much easier to bump epoch or release IMO.

> In this model where version numbers are merely descriptive, other things
> would have to change to use the "build serial" and not the ENVR, since
> the ENVR is now merely descriptive.
>
> For example, from systemd.spec:
>
> Obsoletes:      upstart < 1.2-7
>
> The 1.2-7 is an ENVR, obviously.  But if you think about it, the
> relationship of systemd and upstart here has *nothing* to do with the
> upstream version of 1.2, nor the fact that it was the 7th build.
>
> That 1.2-7 is capturing a *point in time* in Fedora (the combination of
> packages of systemd and upstart), and a point in time is exactly what a
> build serial is.

Let's consider that EVR is an abstraction of point in time. Version marks
point in time for upstream, release marks point in time for Fedora release. In
that case all you need to do is update the "point in time" to more recent
value, i.e. bump the release, right? I don't see anything complicated here,
that's what release numbers are for.

Thanks
Jan

Attachment: signature.asc
Description: This is a digitally signed message part.

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux