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

Re: terminology and the hierarchy of releases



On Tue, Feb 10, 2004 at 05:05:45PM -0200, Alexandre Oliva wrote:
> On Feb 10, 2004, Bill Nottingham <notting redhat com> wrote:
> 
> > Axel Thimm (Axel Thimm physik fu-berlin de) said: 
> 
> >> o If a package has to be removed w/o any replacement, let it be
> >> obsoleted by fedora-release, or a special clean-up package
> >> fedora-remove-obsoleted-developement. It can be argued that this is
> >> not even neccessary to keep upgrade paths, so consider this optional.
> 
> > No, this causes problems if people go to add their own version of it
> > later.
> 
> `it' being the fedora-remove-obsoleted-development package itself, or
> some other package it's purported to clean up?
> 
> I think such an obsoleted package could be a nice thing to have in the
> installer, on updates: the installer would install it (to clean up old
> packages) and then remove it at the end of the installation, such that
> the package wouldn't prevent the installation of the removed package
> again.  It could also obsolete specific version numbers or ranges
> (assuming such a thing is possible).

Yes, it is. If there is a list of packages that have been withdrawn
from "developement" one could automatically crate this package with

Obsoletes: foo = 1.2.3-4
Obsoletes: bar = 1:2.3.4-5
...

It even works with obsoleting prior or even future (!) versions of the
package itself (this has been found by Dag, he wants to use it to
effectively lower the epoch against all natural rpm laws ;).

If a 3rd party outside of developement would package foo and bar with
the same version/release versioning of a package obsoleted that way he
would lose.

Given the tagging jungle of the release part, this is highly unlikely
(and BTW another reason why the release tagging should contain origin,
then no other party should be allowed to tag the release like for
instance Red Hat does). The unfortunate packager would realize this
immediately, if the fedora-remove-obsoleted-development is always
present (for example part of fedora-release).

Please make it easier for people to jump on the testN and development
trains. Effectively requiring from each tester to reinstall from
scratch for each testN or developement release, or be left with
packaging obstructions is not helping deploying and _tracking_ the
test/developement setups (it helps testing anaconda, of course ;).
-- 
Axel Thimm physik fu-berlin de

Attachment: pgp00027.pgp
Description: PGP signature


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