arency
in how a package can move from EPEL into USV support. Then it would
matter less that EPEL is moving packages along at faster rate as EPEL
could focus on those packages that /need/ to move at a faster rate and
let USV handle the common packages as well as those that need stability.
Any way. M
On 04/07/2016 10:33 AM, Dave Johansen wrote:
> https://www.qgis.org/en/site/forusers/visualchangelog214/index.html
> QGIS has adopted a LTR model similar to Firefox and 2.14 is the new LTR.
> I've considered doing what RedHat does with Firefox and updating the
> version of QGIS in EPEL with LTR
On 02/22/2016 09:06 PM, Peter wrote:
> On 19/02/16 15:16, ~Stack~ wrote:
>> Thanks for replying. Makes sense. But what would the harm be to move a
>> package into a separate "retired" repo? Community would know that it
>> isn't maintained and yet the package wou
On 02/18/2016 06:29 PM, Stephen John Smoogen wrote:
> On 18 February 2016 at 14:13, ~Stack~ <i.am.st...@gmail.com> wrote:
>> On 02/18/2016 01:56 PM, Kevin Fenzi wrote:
>>> On Tue, 16 Feb 2016 23:24:58 -0700
>>> Stephen John Smoogen <smo...@gmail.com> wrote
ase that haven't been in the main EPEL repo in a year.
My mirror for just 6 & 7 is ~100GB now. Small price for me since it
doesn't delete which has saved my butt numerous times when a package
suddenly disappears.
Thanks!
~Stack~
signature.asc
D
on it (whoever yanked it apparently didn't bother to check which
packages still depend on it...not the first time EPEL has done this
recently). Fortunately, I sync my own mirrors and I don't delete
packages. :-)
If you need it, I can send it to you.
~Stack~
signature.asc
Description: OpenPGP
