On disttags

[Jeff Spaleta]

On Wed, 19 May 2004 13:03:03 -0500, Rex Dieter <rdieter at math.unl.edu> wrote:
> "3. Do as much of the development work as possible directly in the
> upstream packages. This includes updates; our default policy will be to
> upgrade to new versions for security as well as for bugfix and new
> feature update releases of packages."

As much as possible..does not mean its always going to be possible.
A promise to avoid the need for a backport doesn't mean its not going
to be needed...critically needed. Building a general naming policy
that doesn't leave room for package mainters and leadership to provide
critical security backports when moving to upstream latest is not the
right thing to do, is a mistake,


> IMHO, The only reason dist_tags can possibly cause any sort of 
> problems with backported fixes is dealing with rpm < 4.2 (or possibly rpm < 4.1 where is incorrectly sorts numerics vs. alphas in version/release 
> tags). In the scope of *this* discussion, we're dealing only with 
> non-buggy rpm versions, so Fedora Core can safely ignore those 
> problems(*). Futher, in the lack of existing dist_tags, these problems go > away.

You know, i dont think we can assume that at all. I bet the 3rd party
repository maintainers that are pushing hard for distag to be the
policy want to make damn sure, that the policy works for all the
distros they are trying to build packages for including all those old
red hat releases with those older rpm versions because they want their
build system to be as automated as possible.

And of course this makes an assumption that the fedora core
buildsystem wont have to be constrained by the rhel build process
requirements. I can not speak knowledgably about how much of a burden
tagging like this will place on maintainers who have to consider using
a codebase for both fedora and rhel packages. But I don't think we can
assume out of hand that whatever fedora core buildsys does is going to
be without constraint on how rhel packaging building works. So for the
sake of discussion i dont know if we can assume a buggy rpm is outside
the bounds of the problem.
Fedora project policy is not going to live in a vacuum, and we do not
know enough about the Core buildsystem to know if rhel packaging
considerations have to be taken into account in packaging naming or
not.

-jef