Unstable EPEL

Farkas Levente lfarkas at lfarkas.org
Wed Jul 9 20:39:12 UTC 2008


hi,
i'm just read the current thread about how to release packages in epel. 
imho it's clear that the question is how we can define epel? there are 
many definition, 'by desing' epel = fedora - rhel - [difference]
1, difference is converging to 0 and all other packages at the same 
version as the latest released fedora packages.
2, difference is not converging to 0 and just some stable well tested 
packages from fedora with version 1-2-3 years old.

but the other question who maintain the packages?
a, fedora package maintainers or
b, people close to rh (payed for it, which means those packages which rh 
wouldn't like to support but would be useful to many people).

unfortunately the main problem is none of the above fit into the package 
maintainers point of view. since it seems most people would like to mix 
together '2' with 'a' which is not possible:-( fedora package usually 
would like to follow the latest upstream version (which is imho the 
right behavior). and fedora-6 ~ rhel-5 but now we've got fedora-9! 
packages at the same version as was in fedora-6 will become legacy in 
the near future (not to mention rhel-4) so it's not really maintainable 
in this way.

make something stable and maintain packages by volunteer is not working 
  just see what's happened with debian.

anyway i rather vote for '1' and 'a' pair. eg: i like those fixes which 
comes with newer shorewall versions, what's more i'd like to see 4.0.13 
as soon as it'll be released since it'll contain a fix which is 
important in our environment (and would not like to rebuild all packages 
from fedora which is too old or not in epel). or even some packages from 
rhel can be released with newer versions (eg: gstreamer).

and those who like stable tested packages (which is much more work eg. 
backport bugfixes and security fixes so diverged from the original 
version but still not the latest) should have to ask/request/force rh 
that the given package get into rhel.

or may be a best would be create two different repository (can be called 
anything): '1' and '2', but i bet '2' will be dead soon. may be some 
kind of rules can be defined eg:
- testing and development packages can't get into epel,
- released fedora packages can go into epel testing,
- only after a package be in epel testing for at least one month can be 
get into epel.

just my 2c.

-- 
   Levente                               "Si vis pacem para bellum!"




More information about the epel-devel-list mailing list