[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: EPEL, RHEL-5Server and RHEL-5Client...



I think the right solution is, to move add python imaging to the core
server. In that way it will be available to every user.

I have to review why it was moved to the Client only (it will be
available to server customers in a separate channel containing the
Client-only packages as soon as the RHN profiles get updated). I assume
dependencies where only from that Repo.

We'll target that for 5.1

Regards,

Daniel

On Tue, 2007-07-17 at 12:33 +0200, Thorsten Leemhuis wrote:
> 
> On 17.07.2007 12:13, Joel Andres Granados wrote:
> > 
> > Regarding the python-imaging package...
> > What is the matter with including the 1.1.6 version in EPEL/el5?  does 
> > it break anything?
> > Both Plone and python-docutils (deps in EPEL) use the Image library from 
> > PIL and this library does not have any
> > backward compatibility issues.  additionally, RHEL5-client has no 
> > package that depends on
> > python-imaging.  So I say KISS, and ship 1.1.6 with the EPEL/el5.  I 
> > know it goes against the EPEL policies,
> > but I think its much better that messing with nvr.
> 
> This way lie dragons.
> 
> "EPEL does not replace packages from the distribution it was build for"
> is IMHO not debatable -- just as it was in Extras before the merge.
> 
> For the situations at hand:
> 
> Problem1 -- python-imaging was EPEL: We made a error, but we are still
> in the testing/buildup phase, so we can still remove it from the repo
> and say loudly "apologize" and "we are sorry"(¹). Not ideal, but problem
> solved.
> 
> Problem2 -- python-imaging had a higher EVR then the EL5Client package:
> Ignore those users that got the newer python-imaging from EPEL (see
> Problem 1: "EPEL is still in testing" and "apologize"). Rebuild plone
> and python-docutils against the 1.1.5 package from EL (if that's
> needed). Solved.
> 
> Problem3 -- no python-imaging in EL5Server: Not solved yet, but under
> discussion.
> 
> CU
> thl
> 
> 
> (¹) -- we likely should put something (test-scripts?) in place to make
> sure something similar does not happen again
> 
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list redhat com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
-- 
Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc.
E-Mail: riek redhat com, http://www.redhat.com/
Key-FP: 3DD7 C376 C3E0 1917 9A63  6343 5A26 2C59 6C07 6F32

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]