On Aug 13 01:25, Stephen John Smoogen wrote:
I think that would be something with
softwarecollections.org as that
seems
in line with their way of packaging items. I think that for some sorts of
packages and libraries it makes sense for that, but I don't know if EPEL
would mix and match like that. What I would like to do is the following:
We move from our moving distribution to a point release cycle with a disk
layout like the following:
epel
epel/development/
epel/development/5
epel/development/6
epel/development/7
epel/beta/5.12
epel/beta/6.7
epel/beta/7.1
epel/releases
epel/releases/6.6
epel/releases/5.11
epel/releases/7.0
epel/updates
epel/updates/6.6
epel/updates/5.11
epel/updates/7.0
epel/updates/testing/
epel/updates/testing/6.6
epel/updates/testing/5.11
epel/updates/testing/7.0
epel/development would be like the current EPEL directories but without the
stringent requirements that packages are locked to a specific version for
the lifetime of the overall RHEL release. Instead whenever RHEL releases a
new dot release (7.0, 6.6, 5.11), EPEL would branch off the releases from
development to beta/7.0 or beta/6.6 etc. Packages would be built against
the point release and would need to be tested to get sufficient karma for
'release'. Once 6 weeks have passed from the RHEL point release, all
packages which had gotten enough karma and that had completed repository
trees would be put into epel/releases/6.6. Updates to that package would be
put into updates/testing/6.6 and then promoted to updates/6.6 when enough
karma had been given for an update. New packages which were added after the
point release would show up in updates following the process Fedora does
for new packages between point releases.
Later when 7.1, 6.7, 5.12 (or whatever they are called) comes out then the
process is repeated which will make sure that packages that aren't needed
enough to have sponsors will not be in EPEL and potentially broken and
large updates are possible so if python34 is in 7.0 but python35 is ready
for 7.2 it can replace it without problems (or similarly with ruby23 etc
etc). Once the next point release is made ready, the old point release will
be archived off to keep storage levels within reason.
I know that this proposal needs a lot more fleshing out, but I think it
covers the use cases many users of EPEL need for long term usage of
packages.
--
Stephen J Smoogen.
Were there plans made (at flock or elsewhere) for regular EPEL-related meetings? I would
like
to chip in and help where I can. I think this proposal strikes a happy medium
between stability (within a point-release) and updated features.
--
Brian Stinson
bstinson(a)ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk