Patrice Dumas wrote:

On Wed, Oct 15, 2008 at 10:12:42AM +0200, Denis Leroy wrote:

Thorsten Leemhuis wrote:
Just a note for those not familiar with the habits from Livna/RPM
Fusion: Livna/RPM Fusion normally doesn't take any packages that are
suitable for Fedora (¹).
Can you define "suitable" :-) ? there are some packages that are
suitable in theory, but won't get in without a fight through FeSCo.


Which free software package without patent issue wouldn't be suitable?
Maybe an additional kernel (like the bsd kernel or the HURD, would be
nice, any taker?), but otherwise?


- packages likely to be vetoed by a Red Hat employee (and therefore by
FeSCo): compat-python, compat-gcc-32


- packages that include kernel modules, like open-vm-tools.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Thorsten Leemhuis wrote:

On 15.10.2008 09:17, Oliver Falk wrote:

Kevin Fenzi wrote:

On Tue, 14 Oct 2008 13:02:48 +0200
oliver@linux-kernel.at (Oliver Falk) wrote:


OK. I think I've read the whole old thread now :-)
First of all: I *will* package compat-python and Zope/Plone, because
I need it at work. The only question is if Fedora/FESCo wants me to
share my work with the Fedora community or not!

FYI, note that compat-python24 and compat-zope are already in livna
(and I assume then also rpmfusion). Perhaps you could offer to help
maintain those with their maintainer
there? Even less work, since they are already packaged/used.
I've taken these packages as a starting point. I will need additional
python modules and I do also need compat-python23 and why not take
these packages into Fedora. Why is everyone wicked about maintaining
packages in a third party repository? I know rpmfusion and most
packages seem to be quite good. What's the reason for not taking them
into Fedora - except those packages with non-floss licenses?


Just a note for those not familiar with the habits from Livna/RPM
Fusion: Livna/RPM Fusion normally doesn't take any packages that are
suitable for Fedora (¹).


I do know and I know the footnote as well :-)

Back then we tried our best to get compat-python directly into Fedora,
but those efforts failed. Hence Livna accepted compat-python (and hence
it made its way to RPM Fusion). But I'm all for moving compat-python* to
Fedora, so I really appreciate your efforts Oliver!


This is good news, that you want the same!
I really want to have them in the main repository and I'm willing to
help to get them in and also help you to maintain them, if you like.


I've already raised a FESCo ticket, so they can discuss it in their next
meeting.


[ ... ]

-of

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Denis Leroy wrote:

Thorsten Leemhuis wrote:
Just a note for those not familiar with the habits from Livna/RPM
Fusion: Livna/RPM Fusion normally doesn't take any packages that are
suitable for Fedora (¹).


Can you define "suitable" :-) ? there are some packages that are
suitable in theory, but won't get in without a fight through FeSCo.


What are the allowed weapons?

-of

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 15.10.2008 10:12, Denis Leroy wrote:

Thorsten Leemhuis wrote:
Just a note for those not familiar with the habits from Livna/RPM
Fusion: Livna/RPM Fusion normally doesn't take any packages that are
suitable for Fedora (¹).

Can you define "suitable" :-) ?


Not exactly ;-)

there are some packages that are
suitable in theory, but won't get in without a fight through FeSCo.


Then really try to fight. If you loose in the end then you can knock on
RPM Fusion's door.


Cu
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 15.10.2008 10:21, Denis Leroy wrote:


- packages that include kernel modules, like open-vm-tools.


Which I'd really like to see in RPM Fusion soon. As you iirc known,
there are packages floating around in some places that are based on
older packages that were up for review in Livna. Someone should collect
all of those packages, merge them and put the result up for review in
RPM Fusion; if everything works fine we can have them available in RPM
Fuson by weeks end (I'm willing to do the review is the packager
actually tested that the packages work).


CU
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, Oct 15, 2008 at 10:21:47AM +0200, Denis Leroy wrote:
> Patrice Dumas wrote:
>> On Wed, Oct 15, 2008 at 10:12:42AM +0200, Denis Leroy wrote:
>>> Thorsten Leemhuis wrote:
>>>> Just a note for those not familiar with the habits from Livna/RPM
>>>> Fusion: Livna/RPM Fusion normally doesn't take any packages that
>>>> are suitable for Fedora (¹).
>>> Can you define "suitable" :-) ? there are some packages that are
>>> suitable in theory, but won't get in without a fight through FeSCo.
>>
>> Which free software package without patent issue wouldn't be suitable?
>> Maybe an additional kernel (like the bsd kernel or the HURD, would be
>> nice, any taker?), but otherwise?
>
> - packages likely to be vetoed by a Red Hat employee (and therefore by
> FeSCo): compat-python, compat-gcc-32

Red Hat does not control FESCo. There are Red Hat employees on FESCo,
but each one was elected by the community.

josh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-10-15 at 09:53 +0200, Thorsten Leemhuis wrote:
> On 15.10.2008 09:17, Oliver Falk wrote:
> Back then we tried our best to get compat-python directly into Fedora,
> but those efforts failed. Hence Livna accepted compat-python (and hence
> it made its way to RPM Fusion). But I'm all for moving compat-python* to
> Fedora, so I really appreciate your efforts Oliver!

I am still very very much against the existence of a compat-python* in
Fedora. I'll even go a step further and say that the existence of such
in rpmfusion/livna has actually hurt things rather than helped. Since
rpmfusion/livna has carried this package, there has continued to be no
impetus on the Zope people to actually move forward to a modern version
of python. We had this discussion *OVER* a year ago and at the time a
compat-python was "just going to be for a release". Yet more than a
year later, the situation is exactly the same. And actually, it's worse
now because people have realized that just base python isn't enough --
they need base python plus some set of modules that they care about.
And another group of people will need another set of packages for their
zope/plone deployment[1]. In three years, are we still going to need a
compat-python2.4 for zope/plone in 3 years because, as was mentioned,
we'll be going to python 2.6 in Fedora 11 and python 3 at an unspecified
point beyond that and if python 2.5 is this much trouble, 2.6 and 3 are
going to be far worse.

We don't ship multiple versions of Xorg because a new version of Xorg
breaks some driver, instead we fix drivers. We don't ship multiple
versions of apache because apache2 broke some modules. <insert
infinitely long list of other such things we don't support>. Why should
python be *any* different for zope/plone?

Jeremy

[1] Want to have your zope and plone instances auth to FAS? Guess you
need python-fedora now... How about openid? There's a different module
there. Etc.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
> James Antill wrote:
> [ ... ]
> >> I can think of a Python 2.4 package that lives within the Zope tree to
> >> make it extra hard for others to use it by accident - but I don't think
> >> that this would be neat, seen from a FHS point of view.
> >
> > In some ways this might be doable, at least it has less pain points
> > than packaging it "properly".
>
> I'm not sure what you mean here? Do you mean with properly an
> /usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to
> invite everybody to have a look at the livna packages. Those are fine
> and don't hurt the main python...

% repoquery --repoid=livna --provides compat-python24-imaging
_imaging.so()(64bit)
_imagingft.so()(64bit)
_imagingmath.so()(64bit)
compat-python24-imaging = 1.1.6-1.lvn9
% repoquery --provides python-imaging
_imaging.so()(64bit)
_imagingft.so()(64bit)
_imagingmath.so()(64bit)
python-imaging = 1.1.6-9.fc9
% repoquery --repoid=livna --provides compat-python24-lxml
compat-python24-lxml = 2.0.5-1.lvn9
etree.so()(64bit)
objectify.so()(64bit)
pyclasslookup.so()(64bit)
% repoquery --provides python-lxml
etree.so()(64bit)
objectify.so()(64bit)
pyclasslookup.so()(64bit)
python-lxml = 2.0.8-1.fc9

...those are all "wrong", in that you can get cross python/python24
provides/requires.

> > and you need to
> > make sure that python-foo doesn't pull in compat-python24-bar (and vice
> > versa).
>
> Hm. How should that happen? Especially with koji....

Well that's a big question, the simplest solution we've come up with is
"don't package python24" ... hence my text about that if everything was
kludged into Zope itself (and all the provides removed) it would be
better, in some ways.

--
James Antill <james.antill@redhat.com>
Red Hat
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-10-15 at 10:01 +0200, Oliver Falk wrote:

> > In my opinion, instead, packagers should be co-maintaining the main
> > version when they do a compat package, and that's all.
>
> It's python, it's the holy (Fedora/Red Hat) grail. I think only people
> on the Red Hat payroll are allowed to commit to python CVS, isn't it?
> :-P Sorry, no offense!

I've given python co-maintainer ship to the only non-RH person who has
asked for it. On the other hand, if you seemed sane and I gave it to
you ... and then you broke python so that Zope could work, I'm not
likely to be impressed .

> I think the main version packagers should allowed to have commit access
> to the compat packages instead. In case compat packager breaks main
> version, the main version packager can fix it...

That implies we don't mind it being broken for a while ... given how
important python is we _really_ don't like it breaking in a non-trivial
way (or eg. yum doesn't work, and you can't update out of your problem)

Also that's not how the breaks happen, it's not like you get file
conflicts etc. ... you get multiple dep. providers and there's no way to
fix that by changing the main python package.

--
James Antill <james.antill@redhat.com>
Red Hat
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, Oct 15, 2008 at 09:45:05AM -0400, James Antill wrote:
>
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)

These kind of provides are simply wrong (in my opinion). rpm provides
script should only get the sonames automatically. Other people disagree
because it is what the elf linker does. See also:

https://bugzilla.redhat.com/show_bug.cgi?id=224544

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list