[repo-coord] Re: disttags, useful?? (was Re: python 2.3 for RH7.3)

[Axel Thimm]

On Mon, Dec 20, 2004 at 01:43:16PM +0800, Jeff Pitman wrote:
> On Monday 20 December 2004 05:53, Dag Wieers wrote:
> > > possible. Having such a mechanism would deprecate the entire idea
> > > of having disttags, making our Release munges a lot more
> > > manageable.
> >
> > Smart may be a solution, but disttags don't really harm. I'm not sure
> > why people think disttags or repotags are harmful and should be
> > removed from Release tags.
> 
> Not harmful, per se, they're just very misleading.  Especially now that 
> fc2 packages are applicable to the fc3 distribution.

This has been always the case, most rh9 packages should still be
installable under fc3, I guess. It just makes more sense to use the
build toolchain of the newer distribution.

What perhaps made you think that fc2 and fc3 have a special
releationship is that fedora.us has not published fc3 packages yet and
points to its fc2 repo.

The idea of <buildid><disttag><more> is to have different builds
(<disttag>) of the same sources/patches/config (<buildid>). Placing it
that way makes

o newer buildid always win regardless of the <disttag>, e.g. when a
  newer disttag does not even exist (like in fedora.us' case)
o higher disttags win, when the buildid is the same, e.g you point to
  fc2 and fc3 repos or still hav efc2 packages on a fc3 system.

Since distro-transitions _can_ be smooth the problem's solution must
be done on a fine grained rpm-level, tools like apt or smart can paste
over certain problems, but it's better to have a solution that every
package manager including bare rpm can cope with like disttags.

As a rule of thumb: Don't use disttags for packages truly distribution
independent like firmware, fonts, non-compiled scripts and the like,
otherwise if the packages would yield binary different content for
different distributions use disttags.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20041220/8c8a087e/attachment.bin