Q:
Do you understand the purpose of RHSCL PR EPEL? ;)
You want RHEL, but neither RHSCL nor EPEL is it, nor designed to be it.
That's why I said ...
EPEL's ideal aimpoint, when feasible, should be like RHSCL. ;)
-- bjs
DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith -
On Fri, Feb 26, 2016 at 2:38 PM, Felix Schwarz
wrote:
> Also as a sysadmin I dislike that stuff in EPEL can change at any time
> (whenever the maintainer can not support the old version anymore). If EPEL had
> some kind of "release" (e.g. tied to RHEL point releases)
Am 19.02.2016 um 16:53 schrieb Dave Johansen:
> But as was also mentioned, a lot of packages have jumped on the Chrome
> bandwagon with crazy release cycles and maintaining security fixes in those
> cases is basically impossible for a volunteer effort. From my perspective,
> having a policy that
On Thu, Feb 18, 2016 at 5:22 PM, Stephen John Smoogen
wrote:
> On 18 February 2016 at 16:37, Dave Johansen
> wrote:
> > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith
> wrote:
> >>
> >> Dave Johansen wrote:
> >> > RHSCL is a
On Thu, 18 Feb 2016 17:22:07 -0700
Stephen John Smoogen wrote:
> One of the issues that I am finding is that most software these days
> has only a 3 year lifetime at best.. if you want it to be longer you
> are going to pay for it either by maintaining it yourself or paying
>
On February 18, 2016 7:08:34 PM PST, Michael Stahnke
wrote:
>I was trying to reply to everything inline, but being the responsible
>posters ya'll are, you trimmed and everything leaving context harder to
>just jump in on :)
>
>Way back in the day when I had a lot more
On 18 February 2016 at 16:37, Dave Johansen wrote:
> On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith wrote:
>>
>> Dave Johansen wrote:
>> > RHSCL is a non-starter where I work (and I imagine at other
>> > locations). 2-3 years of support just isn't
Dave Johansen wrote:
> RHSCL is a non-starter where I work (and I imagine at other
> locations). 2-3 years of support just isn't enough to make it a
> worthwhile investment.
Well, there usually _is_ more than one (1) [RH]SCL per RHEL release.
So it's more like 2-3 releases that "rebase" every 2+
On Thu, Feb 18, 2016 at 2:39 PM, Bryan J Smith wrote:
> Stephen John Smoogen wrote:
> > Sorry what I meant that it is built against all of RHEL not just a
> > couple of channels. Again this isn't a promise we ever made, but one
> > people assume we have made (and get
Stephen John Smoogen wrote:
> Sorry what I meant that it is built against all of RHEL not just a
> couple of channels. Again this isn't a promise we ever made, but one
> people assume we have made (and get surprised when they find out
> differently).
I can only imagine how difficult this gets for
On 18 February 2016 at 12:56, Kevin Fenzi wrote:
>
>> 3. Packages are built against all of an Enterprise Linux 'base' (EG
>>whatever is in CentOS/Scientific Linux base).
>
> I thought we were always clear that we built against RHEL.
> But perhaps not.
>
Sorry what I meant
On Thu, 18 Feb 2016 12:11:28 -0800
Joe Julian wrote:
> On February 18, 2016 11:56:54 AM PST, Kevin Fenzi
> wrote:
> >On Tue, 16 Feb 2016 23:24:58 -0700
> >Stephen John Smoogen wrote:
> >
> >...snip...
> >
> >> 2. Packages in EPEL will
On Tue, 16 Feb 2016 23:24:58 -0700
Stephen John Smoogen wrote:
...snip...
> However during that time there have been many
> rules which it has tried to keep:
>
> 1. Do not do disruptive upgrades. Try to backport security fixes or do
>upgrades which do not change API/ABI
13 matches
Mail list logo