Could look into Pulp, https://pulpproject.org/, which I've used in the past to freeze a copy of EPEL locally to avoid updates when I needed to keep systems frozen on specific minor releases of CentOS. Pulp allowed me to efficiently create multiple copies of the EPEL repos that I could point my various systems at, some getting latest and some getting frozen.
- Trey
On Wed, Apr 25, 2018 at 2:07 PM, Fred Liu <Fred_Liu@xxxxxxxx> wrote:
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" <wolfy@xxxxxxxxxxxxxxxxxx> 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" < >> riehecky@xxxxxxxx> >> > 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" < >> riehecky@xxxxxxxx> >> >> 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-leave@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-leave@lists.fedoraproject.org >> >> >> >> >> >> >> >> _______________________________________________ >> >> epel-devel mailing list -- epel-devel@lists. fedoraproject.org >> >> To unsubscribe send an email to >> epel-devel-leave@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-leave@lists.fedoraproject.org >> > >> >> >> >> -- >> Stephen J Smoogen. >> _______________________________________________ >> epel-devel mailing list -- epel-devel@lists. fedoraproject.org >> To unsubscribe send an email to >epel-devel-leave@lists.fedoraproject.org >> _______________________________________________ epel-devel mailing list -- epel-devel@lists. fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
