store | blogs | forums | twitter | facebook | wiki | downloads | support portal
Atomic Secure Linux
It is currently Tue Oct 22, 2019 2:15 am

» Feed - Atomicorp

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: libwebp in Atomic overriding EPEL
Unread postPosted: Tue Aug 18, 2015 10:34 am 
Offline
Forum Regular
Forum Regular

Joined: Tue Aug 01, 2006 2:45 pm
Posts: 573
Location: Netherlands
Hi Scott,

There are libwebp packages in the Atomic repo with the same version as in EPEL. Is there a good reason for overriding the packages in EPEL?

_________________
Lemonbit Internet Dedicated Server Management


Top
 Profile  
Reply with quote  
 Post subject: Re: libwebp in Atomic overriding EPEL
Unread postPosted: Tue Aug 18, 2015 9:16 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin

Joined: Wed Dec 31, 1969 8:00 pm
Posts: 8329
Location: earth
Its duplicated from epel, it is a dependency for SCL PHP 7.0


Top
 Profile  
Reply with quote  
 Post subject: Re: libwebp in Atomic overriding EPEL
Unread postPosted: Wed Aug 19, 2015 5:26 am 
Offline
Forum Regular
Forum Regular

Joined: Tue Aug 01, 2006 2:45 pm
Posts: 573
Location: Netherlands
Why not put a requirement on the EPEL repo? That may be much better than duplicating packages, and consequently overriding them because of the priorities setup in the Atomic repo config, and having the risk of Atomic forgetting to update when EPEL updates that package.

_________________
Lemonbit Internet Dedicated Server Management


Top
 Profile  
Reply with quote  
 Post subject: Re: libwebp in Atomic overriding EPEL
Unread postPosted: Wed Aug 19, 2015 12:48 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin

Joined: Wed Dec 31, 1969 8:00 pm
Posts: 8329
Location: earth
Yeah this is a great question, when it makes sense to duplicate and when not to duplicate. This gets into the kinds of meta problems that you have when running a really large repo (1 million+ systems in any given week, given the systems we see hitting us**)

TL; DR: It made sense to duplicate this for this specific package (SCL PHP 7.0) because of the popularity of this specific project, and not everyone uses EPEL***.

The nitty gritty: There are so many things to talk about here, I dont want to make this a giant response.... Needless to say, nobody ever asks me what its like to do this :P I'm going to use some specific examples to show some ways this can pan out so I dont make this huge. Suffice to say there is no one-size-fits-all approach to running a repo.

* When packaging you always want to ask yourself who the audience is that is going to use this. I use 3 buckets: They are the non-technical, technical, and technical-but-very-busy.

* What is the value proposition for the package. Ie, what business problem is it solving. My buckets are: Compliance, new business functionality, reduce support overhead


Example 1: Asterisk
Bucket: Technical audience, you can expect them to make many steps
Bucket: new business functionality
You can expect this audience to either have a 3rd party repo, or if they dont, they'll *PROBABLY* be OK with adding one. The caveat to that is the kind of application a business would be using, and they may have Approved Product Lists/Approved Vendor Lists. Meaning they might be technically aware of a dependency available from a source like EPEL, but not be allowed to use it for legal/policy reasons. We have many many "enterprise" customers with APL/AVL issues that use the repo for that reason. (ie. They pay for an atomic feed & we handle APL paperwork). We'd duplicate epel packages like speex here.


Example 2: Openvas
Bucket: Technical-but-very-busy
Bucket: Compliance, reduce support overhead
Like the asterisk example above, they have the skills but run thousands of systems & no time. Frequently these are pure RHEL users, frequently with no internet access. They use things like satellite/spacewalk, are restricted by APL's, or dont have the registrations set up because of the size of the environment. We've duplicated libksba here (this is from base on centos, and from util on rhel) since its come up over and over in the forums here and on the openvas lists & irc.

Example 3: PHP Panda
Bucket: Non-technical
Bucket: reduce support overhead
Adoption of any project with the a non-technical audience drops with each additional step required to install it. So you take that into consideration, and the kind of feedback you'd get back from that kind of an audience if their is an issue (they will recognize a problem, but may not have the experience to articulate it in a meaningful way. Then its on you to figure it out from the information provided). Multiply that by the size of the project, in this case I knew it was around 200,000 installs, and extrapolate the impact on an un-resolvable dependency. If this was in a technical bucket, it might have had a chance at being purely external, but if you look at the kinds of business problems epel solves, not a lot of them are are high impact things like php or asterisk (epel dropped asterisk as of EL7. We'll be picking that up, see example 1 above). So in this case, it was duplicated to lower overall support costs, and to increase the rate of adoption.

So there you have it. Since I started Atomic in 2001, Ive seen a lot of things & people come and go that looked promising and didnt pan out (oh redcarpet, how I miss you). In 2001, there was no yum, no git, no fedora, no centos, no epel. There were only 3 or 4 other packagers out there back then, to now with great tools like scl, mock, and copr that make it easier for everyone to do it. There are entire portals dedicated to building communities (like bohdi) around packaging.

Closing note here, Atomic started from single plesk project dimitri asked me to do to prototype a competitor to Microsoft Exchange (this never panned out :P) to what it is now. And for what its worth... the first 2 packages in atomic were clamav and.... <drum roll> PHP.

** There are both public and private repos of our repos that we do not have visibly into to, so we have no idea how big their user bases are. If you'd like to access to the rsync feed for mirroring, let us know.

*** Why dont they use EPEL? Id say its either because they don't know it exists, or they do know it exists, but are provisioning from a local repo for mass deployment reasons.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

» Feed - Atomicorp

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group