Bug 1329752 - Request update to latest version for EPEL7
Summary: Request update to latest version for EPEL7
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: gnuradio
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-22 20:56 UTC by Lamar Owen
Modified: 2017-11-14 13:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-26 13:55:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Lamar Owen 2016-04-22 20:56:30 UTC
Description of problem:
GNURadio and dependencies are old versions in EPEL7

Version-Release number of selected component (if applicable):
3.7.5.1-2.el7

How reproducible:
Always.

Steps to Reproduce:
1.yum install gnuradio
2.
3.

Actual results:
Installs 3.7.5.1

Expected results:
Install current version 3.7.9

Additional info:
UHD and other packages need updating, too......

Comment 1 Jaroslav Škarvada 2016-04-25 09:16:49 UTC
EPEL policy is to have stable packages with mininum updates, not to have the latest versions:

> The packages in the repository should, if possible, be maintained in similar
> ways to the Enterprise Packages they were built against. In other words: have a
> mostly stable set of packages that normally does not change at all and only
> changes if there are good reasons for changes. This is the spirit of a stable
> enterprise environment.
>
> The changes that cant be avoided get routed into different release trees. Only
> updates that fix important bugs (say: data-corruption, security problems,
> really annoying bugs) go to a testing branch for a short time period and then
> are pushed to the stable branch; those people that sign and push the EPEL
> packages to the public repo will skim over the list of updated packages for the
> stable repo to make sure that sure the goal "only important updates for the
> stable branch" is fulfilled. 

I don't think this qualifies as 'changes that cant be avoided'.

Comment 2 Jaroslav Škarvada 2016-04-25 09:17:29 UTC
(In reply to Jaroslav Škarvada from comment #1)
> EPEL policy is to have stable packages with mininum updates, not to have the
> latest versions:
> 
> > The packages in the repository should, if possible, be maintained in similar
> > ways to the Enterprise Packages they were built against. In other words: have a
> > mostly stable set of packages that normally does not change at all and only
> > changes if there are good reasons for changes. This is the spirit of a stable
> > enterprise environment.
> >
> > The changes that cant be avoided get routed into different release trees. Only
> > updates that fix important bugs (say: data-corruption, security problems,
> > really annoying bugs) go to a testing branch for a short time period and then
> > are pushed to the stable branch; those people that sign and push the EPEL
> > packages to the public repo will skim over the list of updated packages for the
> > stable repo to make sure that sure the goal "only important updates for the
> > stable branch" is fulfilled. 
> 
> I don't think this qualifies as 'changes that cant be avoided'.

https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy

Comment 3 Lamar Owen 2016-04-26 13:55:51 UTC
First, thanks for maintaining the packages.  Second, thanks for the pointer to the policy.  I will research to see for myself if the update to the newer version qualifies (at least for me) as 'can't be avoided' (and I'll look at other EPEL packages to see if similar changes to those packages have been classified as 'can't be avoided') and will come back with more information on a new RFE.  I can of course always maintain my own packages.....

For now I'll close this bug.

Comment 4 Lamar Owen 2017-11-14 13:55:38 UTC
Program note: EPEL7 now has GR 3.7.11 in it; thanks guys to finally fixing this!


Note You need to log in before you can comment on or make changes to this bug.