FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 10-06-2010, 12:46 AM
BJ Dierkes
 
Default Conflicting Packages Policy (was: python26 note)

NOTE: This is likely a topic to revisit/finalize in the next EPEL SIG Meeting (every Monday at 19:30 UTC).

Hello all,

I would like to start an official discussion regarding the current policy on conflicting packages. Currently, the EPEL documentation [1] is a bit sparse and does not reflect certain situations (such as the discussion on mod_python26/mod_wsgi26). Per the FPG [1], Fedora packagers should avoid an explicit 'Conflicts: xxxxx' as much as possible. However, due to some new developments in EPEL 5 (namely python26), some situations may require explicitly conflicting packages.

As an example, during my package review for mod_python26 [3] the subject was brought up due to my use of 'Conflicts: mod_python' in the spec for mod_python26. The packages conflict because mod_python and mod_python26 both provide the 'python_module', and the same Apache directives when enabled. Therefore, the two can not be loaded at the same time. The issue would be the same for mod_wsgi and mod_wsgi26 (built against/for python26). In this specific situation, the possible solutions to work around this are:

* Change policy to account for situations like those related to python26 and allow explicit 'Conflicts: xxxxx'
* Silently disable mod_python26 if python_module is already loaded via IfModule [4]


Though the second option (IfModule) is a cleaner approach, it hides the fact that mod_python26 just won't load if mod_python is installed/enabled and assumes the user will know to look at /etc/httpd/conf.d/mod_python26.conf for comments on why that might be. On the other hand, conflicting with mod_python doesn't inform the user why it conflicts... it just conflicts. In my opinion it would be slightly more obvious why mod_python26 would Conflict: mod_python, but I don't know what is collectively in the best interest of EPEL maintainers.

In Fedora, an explicit 'Conflicts: xxxxx' is unwanted behavior and would be troubling/confusing for a lot of users. However, being that EPEL is a different audience and different use case... I would like to open discussion regarding current policy and determine, officially, how these situations should be handled.

References:

[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
[2] http://fedoraproject.org/wiki/Packaging/Guidelines#Conflicts
[3] https://bugzilla.redhat.com/show_bug.cgi?id=638362
[4] http://httpd.apache.org/docs/2.0/mod/core.html#ifmodule

---
derks




_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-06-2010, 11:19 AM
Stephen Gallagher
 
Default Conflicting Packages Policy (was: python26 note)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/2010 08:46 PM, BJ Dierkes wrote:
> NOTE: This is likely a topic to revisit/finalize in the next EPEL SIG Meeting (every Monday at 19:30 UTC).
>
> Hello all,
>
> I would like to start an official discussion regarding the current policy on conflicting packages. Currently, the EPEL documentation [1] is a bit sparse and does not reflect certain situations (such as the discussion on mod_python26/mod_wsgi26). Per the FPG [1], Fedora packagers should avoid an explicit 'Conflicts: xxxxx' as much as possible. However, due to some new developments in EPEL 5 (namely python26), some situations may require explicitly conflicting packages.
>
> As an example, during my package review for mod_python26 [3] the subject was brought up due to my use of 'Conflicts: mod_python' in the spec for mod_python26. The packages conflict because mod_python and mod_python26 both provide the 'python_module', and the same Apache directives when enabled. Therefore, the two can not be loaded at the same time. The issue would be the same for mod_wsgi and mod_wsgi26 (built against/for python26). In this specific situation, the possible solutions to work around this are:
>
> * Change policy to account for situations like those related to python26 and allow explicit 'Conflicts: xxxxx'
> * Silently disable mod_python26 if python_module is already loaded via IfModule [4]
>
>
> Though the second option (IfModule) is a cleaner approach, it hides the fact that mod_python26 just won't load if mod_python is installed/enabled and assumes the user will know to look at /etc/httpd/conf.d/mod_python26.conf for comments on why that might be. On the other hand, conflicting with mod_python doesn't inform the user why it conflicts... it just conflicts. In my opinion it would be slightly more obvious why mod_python26 would Conflict: mod_python, but I don't know what is collectively in the best interest of EPEL maintainers.
>
> In Fedora, an explicit 'Conflicts: xxxxx' is unwanted behavior and would be troubling/confusing for a lot of users. However, being that EPEL is a different audience and different use case... I would like to open discussion regarding current policy and determine, officially, how these situations should be handled.
>
> References:
>
> [1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
> [2] http://fedoraproject.org/wiki/Packaging/Guidelines#Conflicts
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=638362
> [4] http://httpd.apache.org/docs/2.0/mod/core.html#ifmodule
>

Forgive my ignorance, but is there a reason that mod_python26 could not
be patched to provide 'python26_module' instead of 'python_module' for
apache?

Presumably, this name would be defined in the source for mod_python
somewhere.

- --
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkysWyYACgkQeiVVYja6o6Oy1gCggE4c3nDPDl QykgEy6WaKLIZ0
JQUAn10CqNjh7MucoTao+Nn034vYqDis
=1w/0
-----END PGP SIGNATURE-----

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-06-2010, 02:02 PM
Toshio Kuratomi
 
Default Conflicting Packages Policy (was: python26 note)

On Wed, Oct 06, 2010 at 07:19:02AM -0400, Stephen Gallagher wrote:
>
> Forgive my ignorance, but is there a reason that mod_python26 could not
> be patched to provide 'python26_module' instead of 'python_module' for
> apache?
>
> Presumably, this name would be defined in the source for mod_python
> somewhere.
>
The filenames and symbols that mod_python provides aren't the real problem.
The real problem is that the two mod_pythons will link to two different
versions of libpython.so. The symbols in those two libpython versions will
clash if both modules are loaded into apache.

Tangent: I didn't notice the package naming earlier but we probably want
python26-mod_python to match python26-mod_wsgi and the naming of the module
packages for python26.

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-18-2010, 04:24 PM
BJ Dierkes
 
Default Conflicting Packages Policy (was: python26 note)

This topic is up for discussion (again) in the EPEL meeting today at 19:30 UTC. There has been limited feedback via this thread, but if you have any thoughts please post them here or join the meeting in #fedora-meeting.

---
derks



On Oct 5, 2010, at 7:46 PM, BJ Dierkes wrote:

> NOTE: This is likely a topic to revisit/finalize in the next EPEL SIG Meeting (every Monday at 19:30 UTC).
>
> Hello all,
>
> I would like to start an official discussion regarding the current policy on conflicting packages. Currently, the EPEL documentation [1] is a bit sparse and does not reflect certain situations (such as the discussion on mod_python26/mod_wsgi26). Per the FPG [1], Fedora packagers should avoid an explicit 'Conflicts: xxxxx' as much as possible. However, due to some new developments in EPEL 5 (namely python26), some situations may require explicitly conflicting packages.
>
> As an example, during my package review for mod_python26 [3] the subject was brought up due to my use of 'Conflicts: mod_python' in the spec for mod_python26. The packages conflict because mod_python and mod_python26 both provide the 'python_module', and the same Apache directives when enabled. Therefore, the two can not be loaded at the same time. The issue would be the same for mod_wsgi and mod_wsgi26 (built against/for python26). In this specific situation, the possible solutions to work around this are:
>
> * Change policy to account for situations like those related to python26 and allow explicit 'Conflicts: xxxxx'
> * Silently disable mod_python26 if python_module is already loaded via IfModule [4]
>
>
> Though the second option (IfModule) is a cleaner approach, it hides the fact that mod_python26 just won't load if mod_python is installed/enabled and assumes the user will know to look at /etc/httpd/conf.d/mod_python26.conf for comments on why that might be. On the other hand, conflicting with mod_python doesn't inform the user why it conflicts... it just conflicts. In my opinion it would be slightly more obvious why mod_python26 would Conflict: mod_python, but I don't know what is collectively in the best interest of EPEL maintainers.
>
> In Fedora, an explicit 'Conflicts: xxxxx' is unwanted behavior and would be troubling/confusing for a lot of users. However, being that EPEL is a different audience and different use case... I would like to open discussion regarding current policy and determine, officially, how these situations should be handled.
>
> References:
>
> [1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
> [2] http://fedoraproject.org/wiki/Packaging/Guidelines#Conflicts
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=638362
> [4] http://httpd.apache.org/docs/2.0/mod/core.html#ifmodule
>
> ---
> derks
>
>
>
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-18-2010, 04:42 PM
Kevin Fenzi
 
Default Conflicting Packages Policy (was: python26 note)

On Tue, 5 Oct 2010 19:46:53 -0500
BJ Dierkes <wdierkes@5dollarwhitebox.org> wrote:

> NOTE: This is likely a topic to revisit/finalize in the next EPEL SIG
> Meeting (every Monday at 19:30 UTC).
>
> Hello all,
>
> I would like to start an official discussion regarding the current
> policy on conflicting packages. Currently, the EPEL documentation
> [1] is a bit sparse and does not reflect certain situations (such as
> the discussion on mod_python26/mod_wsgi26). Per the FPG [1], Fedora
> packagers should avoid an explicit 'Conflicts: xxxxx' as much as
> possible. However, due to some new developments in EPEL 5 (namely
> python26), some situations may require explicitly conflicting
> packages.
>
> As an example, during my package review for mod_python26 [3] the
> subject was brought up due to my use of 'Conflicts: mod_python' in
> the spec for mod_python26. The packages conflict because mod_python
> and mod_python26 both provide the 'python_module', and the same
> Apache directives when enabled. Therefore, the two can not be loaded
> at the same time. The issue would be the same for mod_wsgi and
> mod_wsgi26 (built against/for python26). In this specific situation,
> the possible solutions to work around this are:
>
> * Change policy to account for situations like those related to
> python26 and allow explicit 'Conflicts: xxxxx'
> * Silently disable mod_python26 if python_module is already loaded
> via IfModule [4]
>
>
> Though the second option (IfModule) is a cleaner approach, it hides
> the fact that mod_python26 just won't load if mod_python is
> installed/enabled and assumes the user will know to look
> at /etc/httpd/conf.d/mod_python26.conf for comments on why that might
> be. On the other hand, conflicting with mod_python doesn't inform
> the user why it conflicts... it just conflicts. In my opinion it
> would be slightly more obvious why mod_python26 would Conflict:
> mod_python, but I don't know what is collectively in the best
> interest of EPEL maintainers.
>
> In Fedora, an explicit 'Conflicts: xxxxx' is unwanted behavior and
> would be troubling/confusing for a lot of users. However, being that
> EPEL is a different audience and different use case... I would like
> to open discussion regarding current policy and determine,
> officially, how these situations should be handled.

So, some more questions I have:

* Would this conflicts case be restricted to just these python26-mod*
packages? Or is this more general? I can see the case for packages
that use a parallel installable stack and can't load at the same
time, but I worry that we should make sure this isn't used more
broadly.

* Perhaps it would be worth making sure we document and require adding
a 'README-conflicts' to any package that has these conflicts with a
more verbose description of why and with what they conflict? Or some
other way to get info to users as to why they conflict?

I guess I would be ok with the conflict in this corner case, but would
want to make sure we discuss/approve any further expansion of it
anywhere.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-18-2010, 07:30 PM
Toshio Kuratomi
 
Default Conflicting Packages Policy (was: python26 note)

On Mon, Oct 18, 2010 at 10:42:08AM -0600, Kevin Fenzi wrote:
>
> So, some more questions I have:
>
> * Would this conflicts case be restricted to just these python26-mod*
> packages? Or is this more general? I can see the case for packages
> that use a parallel installable stack and can't load at the same
> time, but I worry that we should make sure this isn't used more
> broadly.
>
The technical criteria leading to this are:

* Plugins to an app (in this case, mod_{python,wsg} to apache)
* Plugins link to a library that is versioned at the library level but not
versioned/namespaced at the symbol level. (In this case, libpython24.so
and libpython26.so which provide an overlapping set of function names).

Whether to create a general criteria from this or limit it to the specific
case of apache with
mod_python/python26-mod_python/mod_wsgi/python26-mod_wsgi I leave to you :-)

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 10-18-2010, 07:49 PM
David Malcolm
 
Default Conflicting Packages Policy (was: python26 note)

On Mon, 2010-10-18 at 12:30 -0700, Toshio Kuratomi wrote:
> On Mon, Oct 18, 2010 at 10:42:08AM -0600, Kevin Fenzi wrote:
> >
> > So, some more questions I have:
> >
> > * Would this conflicts case be restricted to just these python26-mod*
> > packages? Or is this more general? I can see the case for packages
> > that use a parallel installable stack and can't load at the same
> > time, but I worry that we should make sure this isn't used more
> > broadly.
> >
> The technical criteria leading to this are:
>
> * Plugins to an app (in this case, mod_{python,wsg} to apache)
> * Plugins link to a library that is versioned at the library level but not
> versioned/namespaced at the symbol level. (In this case, libpython24.so
> and libpython26.so which provide an overlapping set of function names).
>
> Whether to create a general criteria from this or limit it to the specific
> case of apache with
> mod_python/python26-mod_python/mod_wsgi/python26-mod_wsgi I leave to you :-)

Attempting to dynamically link a single process against both python 2.4
and python 2.6 is likely to make that process crash.

My understanding is that it's possible for an Apache expert (which I am
not) to set up multiple, independent configurations of httpd on a host,
which would run as separate processes.

With that in mind, it seems reasonable to provide pre-built libraries in
RPM form (e.g. to avoid needing to have a compilation toolchain
installed).

So I think that there is a use-case to have both a python2.4 mod_wsgi
and a python 2.6 mod_wsgi installed via RPM - but it's only of use to
someone prepared to do a lot of reconfiguration of httpd; without that,
one needs to have some kind of stern warning in the configuration.

So I'm not convinced that it's correct to "forbid" this at the RPM
level: there are reasonable situations where you might want both RPMs
installed.

Hope this makes sense
Dave

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

Thread Tools




All times are GMT. The time now is 07:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org