Totally agree. And quick iteration is the nut of Linux especially for personal 
usage. But in enterprise scenario, there's normalization. That is why LTS and 
subscription make sense. I am not gonna troll in ?cathedral and bazaar?. ^:^

Originally I am thinking about downloading rpm packages from EPEL and merging 
these packages into 7.3's ISO file. But it seems rebuilding from source is also 
a good approach!  I will try this way later.

Little bit off-topic, the main purpose to play OL7.5 is to taste kslice and 
dtrace though UEK can be installed/built on SL too. If there is feasible 
hot-kernel-patching, quick iteration will dominate more in enterprise 
on-premise demand.




On Thu, Apr 26, 2018 at 1:27 AM +0800, "Manuel Wolfshant" 
<wo...@nobugconsulting.ro<mailto:wo...@nobugconsulting.ro>> wrote:


On April 25, 2018 6:46:44 PM GMT+03:00, Fred Liu  wrote:
>OK. Then I am thinking about brunch and merge into OS's iso once there
>is
>package update in EPEL.

EPEL always tracks the latest RHEL minor release. If you decide to ignore  all 
the security risks associated with the lack of updates and prefer to freeze 
your system at an old(er) minor release of RHEL (or clone) you will need to 
grab the sources of the updated EPEL packages and rebuild them youself for your 
environment. The EPEL project lacks the resources needed for such a task.

And BTW , you can install the latest EPEL packages on OEL 7.5 because it has 
the updated packages that came with RHEL 7.5 (and which, incidentally, will 
land in the CentOS world very very soon as well).

If you really must use an old minor release you probably should subscribe to 
RHEL EUS. This will ensure a better approach to the security aspect but will 
not solve your issues regarding the  compatibility with EPEL. And pretty 
please, do not imagine that a system not facing the Internet is safe. Stuxnet 
infected air gapped computers.



manuel



>
>Thanks.
>
>Fred
>
>Stephen John Smoogen ?2018?4?25? ????11:40???
>
>> On 25 April 2018 at 10:31, Fred Liu  wrote:
>> > It is understandable. But why not keep the old versions in the very
>same
>> > repo? yum is capable of matching the them with different OSes.
>> >
>>
>> No it isn't. Yum will upgrade you to the latest version in the
>> repository so there would need to be a 7.3 tree and yum would have to
>> point to it. That takes a lot of work on our side and not a lot of
>> people have been interested in doing the work.
>>
>> > Thanks.
>> >
>> > Fred
>> >
>> >
>> >
>> >
>> > On Wed, Apr 25, 2018 at 10:27 PM +0800, "Pat Riehecky" <
>> riehe...@fnal.gov>
>> > wrote:
>> >
>> >> EPEL tracks the latest RHEL release.  There are a number of fixes
>in 7.4
>> >> and 7.5 that are really worth it.
>> >>
>> >> Pat
>> >>
>> >> On 04/25/2018 09:09 AM, Fred Liu wrote:
>> >>
>> >> So abandon SL7.3? Does it mean EPEL doesn't have consistent
>> compatibility?
>> >>
>> >> Thanks.
>> >>
>> >> Fred
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Apr 25, 2018 at 9:57 PM +0800, "Pat Riehecky" <
>> riehe...@fnal.gov>
>> >> wrote:
>> >>
>> >>> I would recommend updating to SL 7.4
>> >>>
>> >>> Pat
>> >>>
>> >>> On 04/25/2018 08:37 AM, Fred Liu wrote:
>> >>> > Hi,
>> >>> >
>> >>> > I used to successfully install mate-desktop on SL7.3 by EPEL7.
>But
>> >>> > today, when I tried again, I saw some incompatibility
>> >>> > issues(glib2,gtk3+,etc). And I can successfully install it on
>OL7.5.
>> >>> > Is normal? From my understanding, EPEL7 should work in both
>> >>> > OSes.
>> >>> >
>> >>> > Any ideas?
>> >>> >
>> >>> >
>> >>> > Thanks.
>> >>> >
>> >>> >
>> >>> > Fred
>> >>> > _______________________________________________
>> >>> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> >>> > To unsubscribe send an email to
>> >>> > epel-devel-le...@lists.fedoraproject.org
>> >>>
>> >>> --
>> >>> Pat Riehecky
>> >>>
>> >>> Fermi National Accelerator Laboratory
>> >>> www.fnal.gov
>> >>> www.scientificlinux.org
>> >>> _______________________________________________
>> >>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> >>> To unsubscribe send an email to
>> epel-devel-le...@lists.fedoraproject.org
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> >> To unsubscribe send an email to
>> epel-devel-le...@lists.fedoraproject.org
>> >>
>> >>
>> >> --
>> >> Pat Riehecky
>> >>
>> >> Fermi National Accelerator Laboratory
>> >> www.fnal.gov
>> >> www.scientificlinux.org
>> >
>> >
>> > _______________________________________________
>> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> > To unsubscribe send an email to
>epel-devel-le...@lists.fedoraproject.org
>> >
>>
>>
>>
>> --
>> Stephen J Smoogen.
>> _______________________________________________
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to
>epel-devel-le...@lists.fedoraproject.org
>>
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Reply via email to