[Fedora-infrastructure-list] Infrastructure Package Management
a.badger at gmail.com
Thu Aug 24 23:43:45 UTC 2006
On Thu, 2006-08-24 at 16:01 -0500, Mike McGrath wrote:
> So in the meeting today we've discussed what to do about our package
> management. At present FC3 will be EOL'd in april(ish). At that time
> many of the packages we use in our environment will become out of
FC3 packages are already out of date, only FC5 and devel are
consistently at close to the latest versions right now. When it goes
EOL, they will start to have unfixed security holes as well as simply
lagging relative to upstream version.
> So options are an upgrade to RHEL5 when it is released (which
> we aren't even done upgrading everything to RHEL4 yet), building and
> supporting our own repo, or try to foster support for centos.karan.org
> or https://extras.108.redhat.com/
To some extent we are going to have to figure out how to keep packages
updated separate from Fedora Extras unless we migrate to Fedora Core on
the servers instead of RHEL. We are going to want the latest versions
of some packages and they won't be available in the relevant FE release.
It would be nice to be able to share resources and manpower with some
other group, though. Currently, centos.karan.org and Extras have
packages and infrastructure to provide updated packages. But there
needs to be manpower (and possibly policy) to allow this.
If we stayed within the Fedora Extras realm, I think we could continue
to use the existing infrastructure (VCS, buildsystem, lookaside cache,
etc) but we'd need to have separate targets RHELX or Infrastructure
that branched from the packages in the Extras tree. Otherwise we'll
conflict with Extras policies surrounding Legacy branches.
We need to hear more from z00dax and quaid to evaluate what policies,
manpower, or infrastructure limitations would exist to maintaining
packages within the centos.karan.org or extra.108 space.
Note: I don't think it would be technically difficult to do this within
Extras infrastructure and the planned additions to that infrastructure
(package database, distributed vcs) should make this even easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20060824/45afba4c/attachment.bin
More information about the infrastructure