RFC: Rethinking EPEL at FUDcon Lawrence 2013
by Stephen John Smoogen
OK from the various problems with various packages and the needs of
packaging groups for a faster place for development and users for a
more stable and knowing release cycle.. I would like to open the floor
to what we can do to make EPEL more useful to both groups as best as
possible with the goal that the proposals are finalized by FUDcon
Lawrence and work on them completed within 6 months.
1) Formalize what EPEL does and how it does it.
- Who gets to decide about updates
- How do we update major items (regularly after a RHEL release? after
a Fedora release?)
- How do we say "we can't support this architecture/release" anymore?
2) Make sure it is documented what the Fedora Build System can do for
us and what it can't.
- Repotags (yes/no)
- Multiple channels for devel, testing, stable, old (yes/no)?
- Building for PPC/etc architectures when we don't have systems anymore?
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
10 years, 11 months
Re: differences between epel and official RHEL-OpenStack
by Mark McLoughlin
Hey Florian,
Good questions, thanks!
Cross-posting to epel-devel because it's related to a recent discussion
about the Essex->Folsom update in EPEL. Apologies if the cross-posting
offends anyone :)
Florian's original mail was:
http://lists.fedoraproject.org/pipermail/cloud/2012-November/001975.html
On Thu, 2012-11-29 at 11:51 +0100, Florian La Roche wrote:
> Hello,
>
> Seems like Red Hat is building the official Red Hat OpenStack product
> rpms sometimes with the exact same name as the ones within EPEL.
>
> The below difference shows that in this case EPEL seems to be a bit ahead,
> but it also looks like this fix is then also not yet merged into the Folsdom
> release that should show up for RHEL6.4.
>
> There are other rpms where also changes are done to dependencies without
> any changelog entry. Often with changing the version name, but not always.
> All this is usually a bad idea.
To clarify one thing, OpenStack isn't in RHEL - Red Hat OpenStack (RHOS)
is layered product separate from RHEL.
Over time, RHOS will evolve in a similar way to RHEL - it will be
supported for longer time periods, there'll be tonnes of backports,
we'll probably skip some releases, etc.
However, we want to make the latest upstream version of OpenStack easily
available for RHEL/CentOS/SL/etc. users and for this to not be subjected
to the kind of constraints RHOS has. Basically, we want the version of
OpenStack that's in Fedora to be available for RHEL/CentOS/SL/etc too.
At the moment, we're using EPEL for this and the RHOS version is very
similar to what's in EPEL. We're currently figuring out how this should
evolve, so your question is pretty topical :)
We learned a lesson with the Folsom update recently. EPEL probably isn't
the best place for "the Fedora version of OpenStack packaged for RHEL":
https://www.redhat.com/archives/epel-devel-list/2012-November/msg00048.html
So, I think we'll probably end up just removing OpenStack from EPEL and
using separate repositories like these ones:
http://repos.fedorapeople.org/repos/openstack/
As for your python-daemon example - it's one of the packages that exists
both in EPEL and RHOS. The two repositories are basically conflicting
over the same n-v-r space, which is bad. We avoid that problem with RHEL
vs EPEL by saying no packages which exist in RHEL should also exist in
EPEL. It's pretty obvious that the same rule doesn't make sense for RHOS
vs EPEL - just because we pull something into RHOS, doesn't mean it
should be removed from EPEL.
The solution we've been assuming so far is yum-priorities. If you use
RHOS and EPEL, your RHOS repo should be configured with a lower priority
number than the default of 99 which is assigned to the EPEL repo.
We probably should have a rhos-release RPM which contains the RHOS .repo
file with a priority and have this RPM depend on the yum-priorities
plugin RPM.
We're also using this scheme to give e.g. the Essex repo higher priority
over EPEL, since EPEL contains the Folsom packages:
http://repos.fedorapeople.org/repos/openstack/openstack-essex/epel-openst...
Phew. Makes sense?
Thanks,
Mark.
11 years
Re: Backwards incompatible change: PowerDNS (2.9.x to 3.1.x)
by James Findley
> On 27.11.2012 12:50, James Findley wrote:
>
> > That is untrue. If your configuration contains the 'wildcards' parameter, powerdns 3.0+ will not start, but it's a supported and valid option for powerdns 2.9. And as it doesn't check the config when restarting, this will cause downtime for unwary users who upgrade.
>
> Hi James,
>
> please note:
>
> http://doc.powerdns.com/changelog.html
>
> The pdns.conf 'wildcards'-setting did not do anything in 3.0, so it was
> removed.
I'm afraid you've rather missed the point. The previous version was 2.9,
where the wildcards setting *DID* do something, and something important at that.
You pushed a direct upgrade from 2.9 to 3.1 that meant that anyone with
this setting in theit pdns.conf would have found their server broken by this change.
There has never been a pdns-3.0 in EPEL so this changelog is not relevent.
>
> > That's again not true. If you have customers with zones without SOAs, these work in 2.9 - they do not work at all in 3.0+.
>
> This is a non-RFC-compliant setup. Zones without SOA record is something
> that you should never do!
>
> RFC 1035:
> [...] 2. Exactly one SOA RR should be present at the top of the zone.
The RFC says "should" not "must" - but this is irrellevent.
Customers can't always be relied upon to produce perfectly RFC
compliant zones, and a zone that worked fine in 2.9 and doesn't
work at all in 3.1 is another very important reason why you should
not have pushed this change.
>
> > I appreciate the work you do to maintain this package in EPEL, but particularly with packages like DNS servers extreme care needs to be taken when deciding to upgrade to a different major version.
> >
> > The powerdns documentation contains numerous warnings that it's not a trivial upgrade - these warnings should have been heeded, especially as the number of bugfixes are fairly small - it's mostly a feature upgrade which should not be a priority for EPEL.
>
> I agree with you fully that we need to be careful with such upgrades.
>
> It isn't really a feature upgrade. The main reason for this decision was
> the security aspect to make sure that we get security patches for
> PowerDNS until 2020.
>
> I can't justify using an old version excluding future security patches.
> The upgrade effort is minimal in relation to the security aspect for the
> next 8 years. For example, the bind version shipped with RHEL 6.0 was
> 9.7.0-P2 and the latest 6.3 release contains bind 9.8.2 RC1. (Yes, I
> know this is only a minor upgrade)
Had there been a critical security vulerability that this change fixed,
you'd have had a better argument. There currently isn't one to the
best of my knowledge.
There may be a pressing security vulnerability that's not trivially
backported to 2.9... or there might not. As of this moment this seems
to me like a gratuitous incompatible change that has been pushed without
proper consideration.
I don't really want to argue this back and forth - I don't think there's
a huge amount that can be done to fix it at this point, so creating a flame-
fest isn't productive.
I would like maintainers to realise that while your efforts are really appreicated
that doing things like this massively reduces the value of EPEL - if everyone
has to do this much diligence checking every update we may as well all roll
our own RPMs.
Thanks for listening,
James
11 years
Fedora EPEL 5 updates-testing report
by updates@fedoraproject.org
The following Fedora EPEL 5 Security updates need testing:
Age URL
43 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13182/ssmtp-2.61...
7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13519/roundcubem...
220 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3....
114 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6608/Django-1.1....
7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13530/pcp-3.6.10...
12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13480/cgit-0.9.1...
46 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13152/cobbler-2....
10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13496/mod_securi...
42 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13192/icecast-2....
The following builds have been pushed to Fedora EPEL 5 updates-testing
dcap-2.47.7-1.el5
drupal7-markdown-1.1-1.el5
imapsync-1.516-1.el5
plowshare-0.9.4-0.38.20121126git.el5
python-bucky-0.2.3-1.el5
xchm-1.21-1.el5
Details about builds:
================================================================================
dcap-2.47.7-1.el5 (FEDORA-EPEL-2012-13583)
Client Tools for dCache
--------------------------------------------------------------------------------
Update Information:
New upstream release.
--------------------------------------------------------------------------------
ChangeLog:
* Tue Nov 27 2012 Mattias Ellert <mattias.ellert(a)fysast.uu.se> - 2.47.7-1
- New upstream release
* Wed Jul 18 2012 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 2.47.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--------------------------------------------------------------------------------
================================================================================
drupal7-markdown-1.1-1.el5 (FEDORA-EPEL-2012-13568)
Provides Markdown filter integration for Drupal input formats.
--------------------------------------------------------------------------------
Update Information:
New upstream version, http://drupal.org/node/1850714.
--------------------------------------------------------------------------------
ChangeLog:
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #880212 - drupal7-markdown-1.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=880212
--------------------------------------------------------------------------------
================================================================================
imapsync-1.516-1.el5 (FEDORA-EPEL-2012-13588)
Tool to migrate email between IMAP servers
--------------------------------------------------------------------------------
Update Information:
Update to 1.516
--------------------------------------------------------------------------------
ChangeLog:
* Tue Nov 27 2012 Nick Bebout <nb(a)fedoraproject.org> - 1.516-1
- Upgrade to 1.516
--------------------------------------------------------------------------------
================================================================================
plowshare-0.9.4-0.38.20121126git.el5 (FEDORA-EPEL-2012-13574)
Download and upload files from file-sharing websites
--------------------------------------------------------------------------------
Update Information:
New upstream snapshot.
--------------------------------------------------------------------------------
ChangeLog:
* Tue Nov 27 2012 Elder Marco <eldermarco(a)fedoraproject.org> - 0.9.4-0.38.20121126git
- New upstream snapshot
--------------------------------------------------------------------------------
================================================================================
python-bucky-0.2.3-1.el5 (FEDORA-EPEL-2012-13573)
CollectD and StatsD adapter for Graphite
--------------------------------------------------------------------------------
Update Information:
Update to 0.2.3
--------------------------------------------------------------------------------
ChangeLog:
* Sat Nov 24 2012 Jonathan Steffan <jsteffan(a)fedoraproject.org> - 0.2.3-1
- Update to 0.2.3
--------------------------------------------------------------------------------
================================================================================
xchm-1.21-1.el5 (FEDORA-EPEL-2012-13578)
A GUI front-end to CHMlib
--------------------------------------------------------------------------------
Update Information:
New upstream release.
--------------------------------------------------------------------------------
ChangeLog:
* Wed Dec 26 2012 Manuel "lonely wolf" Wolfshant <wolfy(a)fedoraproject.org> - 1.21-1
- New upstream version
* Sun Jul 22 2012 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 1.20-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
* Sat Jan 14 2012 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 1.20-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--------------------------------------------------------------------------------
11 years