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
