El Miércoles 01/11/2017 a las 23:58, Peter Rex escribió:
Is gone. Any particular reason?
Yep, mostly security vulnerabilities and 2.x being available, check out these threads for more info:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
Cheers,
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible and my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
On Thu, Nov 2, 2017 at 9:28 AM, Ricardo J. Barberis ricardo@palmtx.com.ar wrote:
El Miércoles 01/11/2017 a las 23:58, Peter Rex escribió:
Is gone. Any particular reason?
Yep, mostly security vulnerabilities and 2.x being available, check out these threads for more info:
https://lists.fedoraproject.org/archives/list/epel-devel@ lists.fedoraproject.org/message/BVB3PXVUFNKKGHGVAOGVNNZODJBFYTMR/ https://lists.fedoraproject.org/archives/list/epel-devel@ lists.fedoraproject.org/message/VZ3BFEZ5526KMZI53MUZL6YZK3Z7EBB2/
Cheers,
Ricardo J. Barberis Usuario Linux Nº 250625: http://counter.li.org/ Usuario LFS Nº 5121: http://www.linuxfromscratch.org/ Senior SysAdmin / IT Architect - www.DonWeb.com _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
On 2 November 2017 at 14:03, Peter Rex prex5609@gmail.com wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible and my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Thank you for your time and your comments. I regret I do not have any better reply than that.
On Thu, Nov 2, 2017 at 9:28 AM, Ricardo J. Barberis ricardo@palmtx.com.ar wrote:
El Miércoles 01/11/2017 a las 23:58, Peter Rex escribió:
Is gone. Any particular reason?
Yep, mostly security vulnerabilities and 2.x being available, check out these threads for more info:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
Cheers,
Ricardo J. Barberis Usuario Linux Nº 250625: http://counter.li.org/ Usuario LFS Nº 5121: http://www.linuxfromscratch.org/ Senior SysAdmin / IT Architect - www.DonWeb.com _______________________________________________ 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
El Jueves 02/11/2017 a las 15:03, Peter Rex escribió:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible and my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
I think that is a bit unfair to the EPEL people, who do an amazing job IMHO.
This is a volunteer-run project (the "E" for enterprise is from upstream -RHEL-, and these are Extra Packages for EL) and sometimes hard decisions have to be made.
For the record: I'm not a contributor to this project, I'm just a user.
From the EPEL Wiki (https://fedoraproject.org/wiki/EPEL#Can_I_rely_on_these_packages.3F):
"Can I rely on these packages?
The EPEL project strives to provide packages with both high quality and stability. However, EPEL is maintained by a community of people who generally volunteer their time and no commercial support is provided. It is the nature of such a project that packages will come and go from the EPEL repositories over the course of a single release. In addition, it is possible that occasionally an incompatible update will be released such that administrator action is required. By policy these are announced in advance in order to give administrators time to test and provide suggestions.
It is strongly recommended that if you make use of EPEL, and especially if you rely upon it, that you subscribe to the epel-announce list. Traffic on this list is kept to a minimum needed to notify administrators of important updates."
Cheers!
On Thu, Nov 2, 2017 at 9:28 AM, Ricardo J. Barberis ricardo@palmtx.com.ar
wrote:
El Miércoles 01/11/2017 a las 23:58, Peter Rex escribió:
Is gone. Any particular reason?
Yep, mostly security vulnerabilities and 2.x being available, check out these threads for more info:
https://lists.fedoraproject.org/archives/list/epel-devel@ lists.fedoraproject.org/message/BVB3PXVUFNKKGHGVAOGVNNZODJBFYTMR/ https://lists.fedoraproject.org/archives/list/epel-devel@ lists.fedoraproject.org/message/VZ3BFEZ5526KMZI53MUZL6YZK3Z7EBB2/
Cheers,
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible and my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
Security flaws mean nothing to the application I use Ansible for, but stability does. Control servers are in private networks, and they configure equipment guarded by murderous thugs, so no problem there.
The control servers don't get updated that often, but when they do, it's not good if things stop working, because, you know, the equipment they configure is owned by people who employ murderous thugs to guard it. Kind of a problem.
We originally looked at Ansible and thought, OK, Red Hat, nothing more stable than that. Ansible, flagship product. It seemed like a good bet, but turned out not to be, that Red Hat wasn't likely to deprecate a major version of a software package during the lifetime of one of its operating systems, in this case EL6. Given how much of a moving target Ansible has turned out to be, I definitely should have subscribed to epel-announce, to, you know, minimize the chance of getting murdered, but here we are.
Anyhow, thanks for the feedback.
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi kevin@scrye.com wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice.
Security,
I guess. I can't resist saying, though, that I regret using Ansible and
my
assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
On 11/03/2017 06:09 AM, Peter Rex wrote:
Security flaws mean nothing to the application I use Ansible for, but stability does. Control servers are in private networks, and they configure equipment guarded by murderous thugs, so no problem there.
The control servers don't get updated that often, but when they do, it's not good if things stop working, because, you know, the equipment they configure is owned by people who employ murderous thugs to guard it. Kind of a problem.
We originally looked at Ansible and thought, OK, Red Hat, nothing more stable than that. Ansible, flagship product. It seemed like a good bet, but turned out not to be, that Red Hat wasn't likely to deprecate a major version of a software package during the lifetime of one of its operating systems, in this case EL6. Given how much of a moving target Ansible has turned out to be, I definitely should have subscribed to epel-announce, to, you know, minimize the chance of getting murdered, but here we are.
Make sure that the murderous thugs do not find out that you confused the stability of RHEL ( which is a commercial product backed by an enterprise which asks for money and delivers services ... and rather long term stable APIs for most of the software they offer ) with the one of EPEL which is a community-driven-best-effort-based product
wolfy ( Who's not afraid of murderous thugs because he's protected by a murderous 3mo old cat -- it murdered several toys already)
Anyhow, thanks for the feedback.
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi <kevin@scrye.com mailto:kevin@scrye.com> wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote: > Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, > I guess. I can't resist saying, though, that I regret using Ansible and my > assumption that one of the Es in EPEL stood for Enterprise. Oh well, live > and learn. Sorry things didn't work out as you would have liked. ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry. You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
They aren't very smart. I'm pretty sure I could pin the blame on Ricardo.
On Fri, Nov 3, 2017 at 6:08 AM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 11/03/2017 06:09 AM, Peter Rex wrote:
Security flaws mean nothing to the application I use Ansible for, but stability does. Control servers are in private networks, and they configure equipment guarded by murderous thugs, so no problem there.
The control servers don't get updated that often, but when they do, it's not good if things stop working, because, you know, the equipment they configure is owned by people who employ murderous thugs to guard it. Kind of a problem.
We originally looked at Ansible and thought, OK, Red Hat, nothing more stable than that. Ansible, flagship product. It seemed like a good bet, but turned out not to be, that Red Hat wasn't likely to deprecate a major version of a software package during the lifetime of one of its operating systems, in this case EL6. Given how much of a moving target Ansible has turned out to be, I definitely should have subscribed to epel-announce, to, you know, minimize the chance of getting murdered, but here we are.
Make sure that the murderous thugs do not find out that you confused the stability of RHEL ( which is a commercial product backed by an enterprise which asks for money and delivers services ... and rather long term stable APIs for most of the software they offer ) with the one of EPEL which is a community-driven-best-effort-based product
wolfy ( Who's not afraid of murderous thugs because he's protected bya murderous 3mo old cat -- it murdered several toys already)
Anyhow, thanks for the feedback.
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi kevin@scrye.com wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice.
Security,
I guess. I can't resist saying, though, that I regret using Ansible and
my
assumption that one of the Es in EPEL stood for Enterprise. Oh well,
live
and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
On 3 November 2017 at 00:09, Peter Rex prex5609@gmail.com wrote:
Security flaws mean nothing to the application I use Ansible for, but stability does. Control servers are in private networks, and they configure equipment guarded by murderous thugs, so no problem there.
The control servers don't get updated that often, but when they do, it's not good if things stop working, because, you know, the equipment they configure is owned by people who employ murderous thugs to guard it. Kind of a problem.
We originally looked at Ansible and thought, OK, Red Hat, nothing more stable than that. Ansible, flagship product. It seemed like a good bet, but turned out not to be, that Red Hat wasn't likely to deprecate a major version of a software package during the lifetime of one of its operating systems, in this case EL6. Given how much of a moving target Ansible has turned out to be, I definitely should have subscribed to epel-announce, to, you know, minimize the chance of getting murdered, but here we are.
OK how can we better explain this in the future? There seems to be some sort of misunderstanding that EPEL is giving the same guarentees as a paid for product from Red Hat. I can understand the grumpiness if you had gotten this under Red Hat contract support and things got bumped. In that case you are paying Red Hat to do that work of keeping software around for N years or it is clear in the contract that this software is not considered 'long term supported'.
In any case you can get a hold of ansible1.9 from https://koji.fedoraproject.org/koji/buildinfo?buildID=690794
Anyhow, thanks for the feedback.
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi kevin@scrye.com wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible and my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
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
El Viernes 03/11/2017 a las 12:09, Stephen John Smoogen escribió:
OK how can we better explain this in the future? There seems to be some sort of misunderstanding that EPEL is giving the same guarentees as a paid for product from Red Hat.
I can't remember which one it was, but there was a repo that when you installed its -release package, it printed a warning in the console that those packages were not guaranteed and out of the support contract you might have with RHEL.
Maybe a post-install/post-upgrade script in epel-release showing such a warning?
On 11/03/2017 05:40 PM, Ricardo J. Barberis wrote:
El Viernes 03/11/2017 a las 12:09, Stephen John Smoogen escribió:
OK how can we better explain this in the future? There seems to be some sort of misunderstanding that EPEL is giving the same guarentees as a paid for product from Red Hat.
I can't remember which one it was, but there was a repo that when you installed its -release package, it printed a warning in the console that those packages were not guaranteed and out of the support contract you might have with RHEL.
Maybe a post-install/post-upgrade script in epel-release showing such a warning?
Anything printed on screen/console will probably be fully and completely ignored in an automated install.
wolfy
El Viernes 03/11/2017 a las 13:12, Manuel Wolfshant escribió:
On 11/03/2017 05:40 PM, Ricardo J. Barberis wrote:
El Viernes 03/11/2017 a las 12:09, Stephen John Smoogen escribió:
OK how can we better explain this in the future? There seems to be some sort of misunderstanding that EPEL is giving the same guarentees as a paid for product from Red Hat.
I can't remember which one it was, but there was a repo that when you installed its -release package, it printed a warning in the console that those packages were not guaranteed and out of the support contract you might have with RHEL.
Maybe a post-install/post-upgrade script in epel-release showing such a warning?
Anything printed on screen/console will probably be fully and completely ignored in an automated install.
wolfy
Sure, but at least it's another option in addition to the wiki and some people will see it.
And hopefuly first timers will do a manual install before automating their processes :)
"SJS" == Stephen John Smoogen smooge@gmail.com writes:
SJS> OK how can we better explain this in the future?
I really tried, in the "Can I rely on these packages?" section of the EPEL wiki page: https://fedoraproject.org/wiki/EPEL#Can_I_rely_on_these_packages.3F
Someone already quoted that in a list message. But if people don't read the relevant web pages then I don't know what we can do. We can't mail root weekly to remind them that EPEL stuff isn't RHEL stuff and doesn't come with the same support guarantees. We can't wrap the download of the epel-release package in a click-through thing where they have to indicate their understanding.
It's simply true that there will always be someone who, for whatever reason, ignores everything we say and carries a different understanding of what EPEL's promise to the community is. It's the same thing that drives people to say "you took something away from me" when we retire a package, even though you can still get the package. And to say "you should support my use case" even though that use case is at odds with reasonable principles of security. I don't think it's any coincidence that all three of those have come up in this one thread.
I don't think there's really anything we can do about it besides making sure the relevant language is available in the right places. And learning to not be bothered when we've met our promises but not someone's misunderstanding of what our promises are.
- J<
Ah thanks, I ended up finding the 1.9.6-2 version on a mirror that hadn't been updated yet. Seems to work fine.
On Fri, Nov 3, 2017 at 9:09 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 3 November 2017 at 00:09, Peter Rex prex5609@gmail.com wrote:
Security flaws mean nothing to the application I use Ansible for, but stability does. Control servers are in private networks, and they
configure
equipment guarded by murderous thugs, so no problem there.
The control servers don't get updated that often, but when they do, it's
not
good if things stop working, because, you know, the equipment they
configure
is owned by people who employ murderous thugs to guard it. Kind of a problem.
We originally looked at Ansible and thought, OK, Red Hat, nothing more stable than that. Ansible, flagship product. It seemed like a good bet,
but
turned out not to be, that Red Hat wasn't likely to deprecate a major version of a software package during the lifetime of one of its operating systems, in this case EL6. Given how much of a moving target Ansible has turned out to be, I definitely should have subscribed to epel-announce,
to,
you know, minimize the chance of getting murdered, but here we are.
OK how can we better explain this in the future? There seems to be some sort of misunderstanding that EPEL is giving the same guarentees as a paid for product from Red Hat. I can understand the grumpiness if you had gotten this under Red Hat contract support and things got bumped. In that case you are paying Red Hat to do that work of keeping software around for N years or it is clear in the contract that this software is not considered 'long term supported'.
In any case you can get a hold of ansible1.9 from https://koji.fedoraproject.org/koji/buildinfo?buildID=690794
Anyhow, thanks for the feedback.
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi kevin@scrye.com wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible
and
my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
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
-- Stephen J Smoogen. _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
Am 03.11.2017 um 16:09 schrieb Stephen John Smoogen:
OK how can we better explain this in the future?
I don't think there is an easy solution with "just another mail to -announce" or so. Personally I don't find it really practical scanning a mailing list for relevant packages (and filtering all the messages which might be "noise" to me because I don't use these packages).
One important thing why I'm using Fedora (and not a rolling release distro) is that I want to have specific points in time when I can prepare for bigger fallout (Fedora releases). This means EPEL could aim to introduce actual "releases" (e.g. every 3 months or so).
Breaking updates would be pushed only at these times (unless there is a *really* good reason). This could involve also writing some release notes (e.g. the packager could tick a box "breaking update" and submit a note which is then added to the release notes).
Currently EPEL is basically a "rolling release" distro which is probably the opposite of what RHEL/CentOS users are looking for.
The second big thing to me is that the "support policy" for each package is not easily discoverable (as far as I know). I suspect it might be especially helpful if there are some kind of "categories" so you grasp the policy very quickly (e.g. "inline with upstream stable", "switch when package is EOLd upstream", "2 years", "just a few months").
So in essence I think EPEL needs to stop pretending it can support packages for a full RHEL lifecycle (= no need for "releases") and unfortunately some extra tooling is required.
Felix
On 11/04/2017 10:35 AM, Felix Schwarz wrote:
Am 03.11.2017 um 16:09 schrieb Stephen John Smoogen:
OK how can we better explain this in the future?
I don't think there is an easy solution with "just another mail to -announce" or so. Personally I don't find it really practical scanning a mailing list for relevant packages (and filtering all the messages which might be "noise" to me because I don't use these packages).
Agreed. I don't know if anyone else does this, but I subscribe to all of the RSS feeds I can find on relevant topics. I poll them from my Nextcloud RSS (to distribute the list to all my devices) then combined with Liferea RSS feed reader (to keep a long search able history on my primary desktop) gives me quite a bit of information.
I don't necessarily "care" that $DISTRO just released $NEW_PACKAGE or deprecated $OLD_PACKAGE or release security patch for $PACKAGE, but it gives me 1) a notification that *something* did change 2) that quick search-able history when I suspect a package update just broke something as my first go-to.
Unfortunately, the RSS feed that I was subscribed to for epel-announce was just a scraper for the online archives which broke some time back. To my knowledge (I would LOVE for someone to prove me wrong, but I just looked again), EPEL does not have a RSS feed for this information (though they DO have an RSS for wiki changes...but that's not something I'm interested in :). I know Fedora[1] provides tons of RSS feeds but I don't know how difficult it would be for EPEL to piggy-back off of them.
[1] Just one example: http://fedoraplanet.org/infofeed/
One important thing why I'm using Fedora (and not a rolling release distro) is that I want to have specific points in time when I can prepare for bigger fallout (Fedora releases). This means EPEL could aim to introduce actual "releases" (e.g. every 3 months or so).
Breaking updates would be pushed only at these times (unless there is a *really* good reason). This could involve also writing some release notes (e.g. the packager could tick a box "breaking update" and submit a note which is then added to the release notes).
In theory, I agree. However, that seems like a lot more work and I honestly don't know if there are enough EPEL users who would appreciate the feature to justify the amount of work that would require. It's an interesting discussion point but in my (self-admittedly small understanding of EPEL behind-the-scenes) view is that is a BIG ask with potentially small impact. Again, I'd love to be proven wrong on this which is why it might make for interesting discussion. :-)
Currently EPEL is basically a "rolling release" distro which is probably the opposite of what RHEL/CentOS users are looking for.
To some extent. I can pull together a list of a dozen packages I *wish* would be updated in EPEL. I can also pull together a list of packages that I'm dreading when they get updated. For me and my small use case, it's about 95% where I need it to be. For the 2% where I really need newer, IUS covers that quite well.
The second big thing to me is that the "support policy" for each package is not easily discoverable (as far as I know). I suspect it might be especially helpful if there are some kind of "categories" so you grasp the policy very quickly (e.g. "inline with upstream stable", "switch when package is EOLd upstream", "2 years", "just a few months").
I agree with this. I have to do it so rarely that it takes me ages of digging around in the Fedora koji system to figure out package information. There's a lot of good information in there, but sometimes it takes a TON of effort to dig it out.
So in essence I think EPEL needs to stop pretending it can support packages for a full RHEL lifecycle (= no need for "releases") and unfortunately some extra tooling is required.
Again, this is my limited view but I can't really recall anyone from EPEL leadership/developers who have claimed that. However, I can pretty easily dig up several responses similar to "EPEL is a best effort from volunteers to provide missing pieces to USV".
Honestly, I wish USV had a mechanism in place that allowed more community feedback into what packages were maintained up stream.
Here's one example. I personally know 5 admins from Red Hat who run htop on the many corporate Red Hat servers they manage. They pull from EPEL. Their internal voice counts, but not as high as customers. That same htop from EPEL package is installed on nearly every one of my CentOS and Scientific Linux friends servers. At least two of that group have server counts in the multiple 1000's. Because they are not RH customers, their voice counts for very little. I, as RH customer (+Scientific Linux), supposedly have a "louder" voice in my vote on having htop be package in the default repos, but every time I pester them about it I basically get brushed off saying that it isn't a "high demand package". Grrrrrr...I know for a fact that at least a dozen other RH customers claim they've asked for htop. It would be nice if there was a touch more transparency 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. My 2 cents. :-) ~Stack~
P.S. Seriously, if you know a good RSS feed for following EPEL announcement, please let me know. I've not figured out how to get an RSS out of Fedora Hyperkitty yet. :-)
On 11/04/2017 08:35 AM, Felix Schwarz wrote:
Am 03.11.2017 um 16:09 schrieb Stephen John Smoogen:
OK how can we better explain this in the future?
I don't think there is an easy solution with "just another mail to -announce" or so. Personally I don't find it really practical scanning a mailing list for relevant packages (and filtering all the messages which might be "noise" to me because I don't use these packages).
One important thing why I'm using Fedora (and not a rolling release distro) is that I want to have specific points in time when I can prepare for bigger fallout (Fedora releases). This means EPEL could aim to introduce actual "releases" (e.g. every 3 months or so).
Breaking updates would be pushed only at these times (unless there is a *really* good reason). This could involve also writing some release notes (e.g. the packager could tick a box "breaking update" and submit a note which is then added to the release notes).
Currently EPEL is basically a "rolling release" distro which is probably the opposite of what RHEL/CentOS users are looking for.
We have talked about doing this kind of thing in the past, but... it's a ton more work (you have to have releng folks do a bunch of work every 3 months or whatever) and we could never agree on the timing. Is it just randomly every 3 months? everytime a new RHEL minor is out? Every time a new CentOS minor is out?
The second big thing to me is that the "support policy" for each package is not easily discoverable (as far as I know). I suspect it might be especially helpful if there are some kind of "categories" so you grasp the policy very quickly (e.g. "inline with upstream stable", "switch when package is EOLd upstream", "2 years", "just a few months").
While all the modularity work in Fedora is all early days and up in the air, this may be something we get "for free" from it. Branches now have a SLA in Fedora, we should be able to leverage that and expose it better to users. Of course everything may change with modules, it's really early to tell. We may be able to make different modules with different SLAs...
kevin
On Sat, 2017-11-04 at 10:33 -0700, Kevin Fenzi wrote:
Breaking updates would be pushed only at these times (unless there is a *really* good reason). This could involve also writing some release notes (e.g. the packager could tick a box "breaking update" and submit a note which is then added to the release notes).
Currently EPEL is basically a "rolling release" distro which is probably the opposite of what RHEL/CentOS users are looking for.
We have talked about doing this kind of thing in the past, but... it's a ton more work (you have to have releng folks do a bunch of work every 3 months or whatever) and we could never agree on the timing. Is it just randomly every 3 months? everytime a new RHEL minor is out? Every time a new CentOS minor is out?
With the perspective of someone who has seen the described problem repeatedly as an EPEL contributor, does it really matter which one option is chosen?
regards, Nikos
Dne 3.11.2017 v 05:09 Peter Rex napsal(a):
We originally looked at Ansible and thought, OK, Red Hat, nothing more stable than that. Ansible, flagship product. It seemed like a good bet, but turned out not to be, that Red Hat wasn't likely to deprecate a major version of a software package during the lifetime of one of its operating systems, in this case EL6.
I think this need to emphasize. Ansible is both project and product. You can buy Ansible product from Red Hat. Then you get predictable EOL and support.
And you can install either packages from upstream Ansible project or install packages from Extra Packages repository. But this is not a product. You get what you paid for.
The free stuff is for people who do not care (too much) if things get broken. When you operate important things, you really should get support. It does not mean just somebody on the phone.
We (Red Hat people and lots of volunteers) are providing a lot of things for free. But we cannot do everything.
Mirek
You seem to be the guy who does the builds. If you could advise, despite the grumpiness:
Since updating Ansible playbooks, tasks, libraries and such to work with a more current Ansible version isn't practical, on existing servers, we're thinking of adding "exclude=ansible1.9 ansible" to the relevant section of the "epel.repo" config file to keep it at 1.9, and on new servers, just install the old ansible1.9 package via RPM (which I managed to find on a mirror that hadn't been updated yet).
However, I'm wondering if we should worry about future changes to dependencies. Most are in @base so I doubt they will stop working with an older versions of Ansible, but do you think we should "exclude" other @epel packages in Ansible 1.9's spec file, or do you think they would they keep working with Ansible 1.9 even if they were updated in the future. The only other @epel package in use on the control servers is git, which shares no common dependencies with ansible1.9.
Writing that down, I think I answered my own question (answer = why not "exclude" them from yum update?), but if you have an opinion you're willing to share, please do. The other @epel package dependencies are:
python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar sshpass
# rpm -qp ansible1.9-1.9.6-2.el6.noarch.rpm --requires /usr/bin/python PyYAML config(ansible1.9) = 1.9.6-2.el6 python(abi) = 2.6 python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar python-paramiko python-setuptools python-simplejson python-six rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 sshpass rpmlib(PayloadIsXz) <= 5.2-1
# repoquery --requires ansible /usr/bin/python2.6 PyYAML python(abi) = 2.6 python-crypto python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar python-paramiko python-setuptools python-simplejson python-six python2-jmespath sshpass
# yum history info 7 Loaded plugins: fastestmirror Transaction ID : 7 Begin time : Fri Nov 3 12:13:07 2017 Begin rpmdb : 218:9695f8cd22db900948a11d2d1346ec6f4728e54a End time : 12:13:22 2017 (15 seconds) End rpmdb : 234:5cef426bcb5a193a4595179386f2b1900998507b User : root <root> Return-Code : Success Command Line : install ansible1.9-1.9.6-2.el6.noarch.rpm Transaction performed with: Installed rpm-4.8.0-55.el6.i686 @CentOS/6.9 Installed yum-3.2.29-81.el6.centos.noarch @CentOS/6.9 Installed yum-plugin-fastestmirror-1.1.30-40.el6.noarch @CentOS/6.9 Packages Altered: Dep-Install PyYAML-3.10-3.1.el6.i686 @base Install ansible1.9-1.9.6-2.el6.noarch @/ansible1.9-1.9.6-2.el6.noarch Dep-Install libyaml-0.1.3-4.el6_6.i686 @base Dep-Install python-babel-0.9.4-5.1.el6.noarch @base Dep-Install python-crypto-2.0.1-22.el6.i686 @base Dep-Install python-crypto2.6-2.6.1-2.el6.i686 @epel Dep-Install python-httplib2-0.7.7-1.el6.noarch @epel Dep-Install python-jinja2-26-2.6-3.el6.noarch @epel Dep-Install python-keyczar-0.71c-1.el6.noarch @epel Dep-Install python-markupsafe-0.9.2-4.el6.i686 @base Dep-Install python-paramiko-1.7.5-2.1.el6.noarch @base Dep-Install python-pyasn1-0.0.12a-1.el6.noarch @base Dep-Install python-setuptools-0.6.10-3.el6.noarch @base Dep-Install python-simplejson-2.0.9-3.1.el6.i686 @base Dep-Install python-six-1.9.0-2.el6.noarch @base Dep-Install sshpass-1.06-1.el6.i686 @epel history info
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi kevin@scrye.com wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice.
Security,
I guess. I can't resist saying, though, that I regret using Ansible and
my
assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
On 3 November 2017 at 17:28, Peter Rex prex5609@gmail.com wrote:
You seem to be the guy who does the builds. If you could advise, despite the grumpiness:
Since updating Ansible playbooks, tasks, libraries and such to work with a more current Ansible version isn't practical, on existing servers, we're thinking of adding "exclude=ansible1.9 ansible" to the relevant section of the "epel.repo" config file to keep it at 1.9, and on new servers, just install the old ansible1.9 package via RPM (which I managed to find on a mirror that hadn't been updated yet).
However, I'm wondering if we should worry about future changes to dependencies. Most are in @base so I doubt they will stop working with an older versions of Ansible, but do you think we should "exclude" other @epel packages in Ansible 1.9's spec file, or do you think they would they keep working with Ansible 1.9 even if they were updated in the future. The only other @epel package in use on the control servers is git, which shares no common dependencies with ansible1.9.
Writing that down, I think I answered my own question (answer = why not "exclude" them from yum update?), but if you have an opinion you're willing to share, please do. The other @epel package dependencies are:
What I normally do in an enterprise setting is get the packages I am going to install on the boxes and collect them to their own repository. I then sign those packages with a rpm key that I control and then have all the client boxes point to that repository. That way I have better control of what is available to clients and if someone decides that weechat should be installed on a server.. they will have had to convince the change control team that it was needed. If the systems were really change control or security critical, I make sure I copy the source code for any auditing purposes or for rebuilding/patching on my own as needed later. The steps in setting up such a repository flow control is:
<EPEL> -- reposync --> <Local EPEL mirror> -- copy files I want installed --> <Local Repo> --> Systems.
The below package list looks correct.
python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar sshpass
# rpm -qp ansible1.9-1.9.6-2.el6.noarch.rpm --requires /usr/bin/python PyYAML config(ansible1.9) = 1.9.6-2.el6 python(abi) = 2.6 python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar python-paramiko python-setuptools python-simplejson python-six rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 sshpass rpmlib(PayloadIsXz) <= 5.2-1
# repoquery --requires ansible /usr/bin/python2.6 PyYAML python(abi) = 2.6 python-crypto python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar python-paramiko python-setuptools python-simplejson python-six python2-jmespath sshpass
# yum history info 7 Loaded plugins: fastestmirror Transaction ID : 7 Begin time : Fri Nov 3 12:13:07 2017 Begin rpmdb : 218:9695f8cd22db900948a11d2d1346ec6f4728e54a End time : 12:13:22 2017 (15 seconds) End rpmdb : 234:5cef426bcb5a193a4595179386f2b1900998507b User : root <root> Return-Code : Success Command Line : install ansible1.9-1.9.6-2.el6.noarch.rpm Transaction performed with: Installed rpm-4.8.0-55.el6.i686 @CentOS/6.9 Installed yum-3.2.29-81.el6.centos.noarch @CentOS/6.9 Installed yum-plugin-fastestmirror-1.1.30-40.el6.noarch @CentOS/6.9 Packages Altered: Dep-Install PyYAML-3.10-3.1.el6.i686 @base Install ansible1.9-1.9.6-2.el6.noarch @/ansible1.9-1.9.6-2.el6.noarch Dep-Install libyaml-0.1.3-4.el6_6.i686 @base Dep-Install python-babel-0.9.4-5.1.el6.noarch @base Dep-Install python-crypto-2.0.1-22.el6.i686 @base Dep-Install python-crypto2.6-2.6.1-2.el6.i686 @epel Dep-Install python-httplib2-0.7.7-1.el6.noarch @epel Dep-Install python-jinja2-26-2.6-3.el6.noarch @epel Dep-Install python-keyczar-0.71c-1.el6.noarch @epel Dep-Install python-markupsafe-0.9.2-4.el6.i686 @base Dep-Install python-paramiko-1.7.5-2.1.el6.noarch @base Dep-Install python-pyasn1-0.0.12a-1.el6.noarch @base Dep-Install python-setuptools-0.6.10-3.el6.noarch @base Dep-Install python-simplejson-2.0.9-3.1.el6.i686 @base Dep-Install python-six-1.9.0-2.el6.noarch @base Dep-Install sshpass-1.06-1.el6.i686 @epel history info
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi kevin@scrye.com wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible and my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
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
Thanks, Stephen, this is good advice, and if I ever deploy Red Hat in an enterprise and not a thug-infested nightmare, I'll take it. For now, I'll wing it and if it goes wrong, send some thugs to deliver a little nightly CI to James. J/k, I guess.
On Fri, Nov 3, 2017 at 6:20 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 3 November 2017 at 17:28, Peter Rex prex5609@gmail.com wrote:
You seem to be the guy who does the builds. If you could advise, despite
the
grumpiness:
Since updating Ansible playbooks, tasks, libraries and such to work with
a
more current Ansible version isn't practical, on existing servers, we're thinking of adding "exclude=ansible1.9 ansible" to the relevant section
of
the "epel.repo" config file to keep it at 1.9, and on new servers, just install the old ansible1.9 package via RPM (which I managed to find on a mirror that hadn't been updated yet).
However, I'm wondering if we should worry about future changes to dependencies. Most are in @base so I doubt they will stop working with an older versions of Ansible, but do you think we should "exclude" other
@epel
packages in Ansible 1.9's spec file, or do you think they would they keep working with Ansible 1.9 even if they were updated in the future. The
only
other @epel package in use on the control servers is git, which shares no common dependencies with ansible1.9.
Writing that down, I think I answered my own question (answer = why not "exclude" them from yum update?), but if you have an opinion you're
willing
to share, please do. The other @epel package dependencies are:
What I normally do in an enterprise setting is get the packages I am going to install on the boxes and collect them to their own repository. I then sign those packages with a rpm key that I control and then have all the client boxes point to that repository. That way I have better control of what is available to clients and if someone decides that weechat should be installed on a server.. they will have had to convince the change control team that it was needed. If the systems were really change control or security critical, I make sure I copy the source code for any auditing purposes or for rebuilding/patching on my own as needed later. The steps in setting up such a repository flow control is:
<EPEL> -- reposync --> <Local EPEL mirror> -- copy files I want installed --> <Local Repo> --> Systems.
The below package list looks correct.
python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar sshpass
# rpm -qp ansible1.9-1.9.6-2.el6.noarch.rpm --requires /usr/bin/python PyYAML config(ansible1.9) = 1.9.6-2.el6 python(abi) = 2.6 python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar python-paramiko python-setuptools python-simplejson python-six rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 sshpass rpmlib(PayloadIsXz) <= 5.2-1
# repoquery --requires ansible /usr/bin/python2.6 PyYAML python(abi) = 2.6 python-crypto python-crypto2.6 python-httplib2 python-jinja2-26 python-keyczar python-paramiko python-setuptools python-simplejson python-six python2-jmespath sshpass
# yum history info 7 Loaded plugins: fastestmirror Transaction ID : 7 Begin time : Fri Nov 3 12:13:07 2017 Begin rpmdb : 218:9695f8cd22db900948a11d2d1346ec6f4728e54a End time : 12:13:22 2017 (15 seconds) End rpmdb : 234:5cef426bcb5a193a4595179386f2b1900998507b User : root <root> Return-Code : Success Command Line : install ansible1.9-1.9.6-2.el6.noarch.rpm Transaction performed with: Installed rpm-4.8.0-55.el6.i686
@CentOS/6.9
Installed yum-3.2.29-81.el6.centos.noarch@CentOS/6.9
Installed yum-plugin-fastestmirror-1.1.30-40.el6.noarch@CentOS/6.9
Packages Altered: Dep-Install PyYAML-3.10-3.1.el6.i686 @base Install ansible1.9-1.9.6-2.el6.noarch @/ansible1.9-1.9.6-2.el6.noarch Dep-Install libyaml-0.1.3-4.el6_6.i686 @base Dep-Install python-babel-0.9.4-5.1.el6.noarch @base Dep-Install python-crypto-2.0.1-22.el6.i686 @base Dep-Install python-crypto2.6-2.6.1-2.el6.i686 @epel Dep-Install python-httplib2-0.7.7-1.el6.noarch @epel Dep-Install python-jinja2-26-2.6-3.el6.noarch @epel Dep-Install python-keyczar-0.71c-1.el6.noarch @epel Dep-Install python-markupsafe-0.9.2-4.el6.i686 @base Dep-Install python-paramiko-1.7.5-2.1.el6.noarch @base Dep-Install python-pyasn1-0.0.12a-1.el6.noarch @base Dep-Install python-setuptools-0.6.10-3.el6.noarch @base Dep-Install python-simplejson-2.0.9-3.1.el6.i686 @base Dep-Install python-six-1.9.0-2.el6.noarch @base Dep-Install sshpass-1.06-1.el6.i686 @epel history info
On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi kevin@scrye.com wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible
and
my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
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
-- Stephen J Smoogen. _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
Dne 4.11.2017 v 01:20 Stephen John Smoogen napsal(a):
What I normally do in an enterprise setting is get the packages I am going to install on the boxes and collect them to their own repository. I then sign those packages with a rpm key that I control and then have all the client boxes point to that repository. That way I have better control of what is available to clients and if someone decides that weechat should be installed on a server.. they will have had to convince the change control team that it was needed. If the systems were really change control or security critical, I make sure I copy the source code for any auditing purposes or for rebuilding/patching on my own as needed later. The steps in setting up such a repository flow control is:
<EPEL> -- reposync --> <Local EPEL mirror> -- copy files I want installed --> <Local Repo> --> Systems.
And on the enterprise level you can do that using: https://theforeman.org/plugins/katello/ (for free, without support) or with Red Hat Satellite (the same, but with support).
Mirek
On 3 Nov 2017 9:28 pm, "Peter Rex" prex5609@gmail.com wrote:
You seem to be the guy who does the builds. If you could advise, despite the grumpiness:
Since updating Ansible playbooks, tasks, libraries and such to work with a more current Ansible version isn't practical, on existing servers, we're thinking of adding "exclude=ansible1.9 ansible" to the relevant section of the "epel.repo" config file to keep it at 1.9, and on new servers, just install the old ansible1.9 package via RPM (which I managed to find on a mirror that hadn't been updated yet).
I'll just stop you right there a second.
Not practical?
Ansible 2 was released nearly 2 years ago.
There's not that much work to port 1.9 code over and there's substantial gains from using a 2+ codebase.
You really should be doing some automated testing of your ansible code, even if it's just a syntax check and lint to pick up deprecation.
Do keep in mind the controlling system is the only one where the version of ansible matters... you don't need to screw around with your repo config on target systems.
The best place to get a package no longer in the current repo is koji rather than trying to dig out a mirror that hasn't replicated in over a year.
For future reference, it's worth having your preferred CI (Jenkins or gitlab etc) use nightlies (docker container makes this trivial) run a syntax check against your playbooks to avoid this happening again.
Upstream provides rpms to make this simple.
On 11/02/2017 03:48 PM, Kevin Fenzi wrote:
On 11/02/2017 11:03 AM, Peter Rex wrote:
Thanks for the info, Ricardo. Hadn't found the retirement notice. Security, I guess. I can't resist saying, though, that I regret using Ansible and my assumption that one of the Es in EPEL stood for Enterprise. Oh well, live and learn.
Sorry things didn't work out as you would have liked.
ansible1.9 was always intended as a short term 'bridge' to help give folks more time to migrate to 2.0. When upstream stopped supporting it, we retired it in EPEL as well. ansible is very very fast moving and complex and there's no way we could backport even security fixes to an out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it doesn't get any bugfixes or security updates.
kevin
This highlights a problem I've occasionally had with EPEL, namely that packages I depend on occasionally get removed. This especially causes trouble when a package gets removed because it's now in RHEL, because it takes a few months for CentOS and Scientific Linux to update. Perhaps you could create an 'epel-unsupported' repo and move packages there instead of removing them?
Thanks, -Mat
On Tue, 7 Nov 2017, Mátyás Selmeci wrote:
This highlights a problem I've occasionally had with EPEL, namely that packages I depend on occasionally get removed. This especially causes trouble when a package gets removed because it's now in RHEL, because it takes a few months for CentOS and Scientific Linux to update. Perhaps you could create an 'epel-unsupported' repo and move packages there instead of removing them?
As others have suggested, running a private mirror of (at least) the SRPMs and learning how to build them, or a larger mirror including binaries, and optionally locally '[re-]signing' them as Smooge mentioned {nice trick, btw, smooge} comes to mind. I don't have to fiddle with the underlying scripts except to add new point releases (of CentOS), and less frequently, of EPEL
People have tried over the years to put together busineses (Progeny, me) or community projects (Fedora Legacy), but economically finding the paying customer mass (and it may well not exist) is not there to justify doing that as a 'full time' occupation, so it rather becomes an adjunct to consulting when custom building, ports, and back-ports
for i in lftp-epel-6.conf lftp-epel-7.conf lftp-epel-testing-6.conf lftp-epel-testing-7.conf ; do NONCE=` grep -v ^# $i | tail -n 1 ` ; du -sh ${NONCE} ; find ${NONCE} -type f | wc -l ; echo "" ; done
11G /share/MD0_DATA/Mirror/redhat/epel/6 5966
17G /share/MD0_DATA/Mirror/redhat/epel/7 6534
709M /share/MD0_DATA/Mirror/redhat/epel/testing/6 391
2.3G /share/MD0_DATA/Mirror/redhat/epel/testing/7 953
... I have a bit north of 750k SRPMS in my local archive and a suite of tools to handle that porting and back-porting developed over ... almost 20 years ... goodness
-- Russ herrold
epel-devel@lists.fedoraproject.org
-
Felix Schwarz -
James Hogarth -
Jason L Tibbitts III -
Kevin Fenzi -
Manuel Wolfshant -
Miroslav Suchý -
Mátyás Selmeci -
Nikos Mavrogiannopoulos -
Peter Rex -
R P Herrold -
Ricardo J. Barberis -
Stephen John Smoogen -
~Stack~