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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-19-2010, 09:27 AM
Brian Harring
 
Default Packages pulling in python-3*, also they dont require it

On Fri, Mar 19, 2010 at 10:01:05AM +0000, Ciaran McCreesh wrote:
> On Fri, 19 Mar 2010 02:56:08 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > We are waiting on ABI dependencies (and extended support for
> > > multiple ABIs in package manager), which will provide some needed
> > > functionality.
> >
> > You can do it now w/out waiting on ABI dependencies- I'm not saying
> > the dependencies would be pretty, but it's doable to get abi level
> > depdencies per slotting via expanding out the use combinations.
> >
> > Note that's a step beyond what's in place now- converting over to the
> > ruby abuse of USE_EXPAND hands over better control to users now w/
> > the same dep gurantees.
> >
> > So... yeah, it's not reliant on EAPI. An EAPI extension *would* make
> > it easier, but it's not required to do it (especially since the deps
> > are already autogenerated to a decent degree).
>
> How would do it and deal with existing packages not having the required
> things in IUSE without (+)/(-) use deps? I don't see a way of doing it
> legally without those.

Roughly,

PYTHON_DEPS="pkg1 pkg2 pkg3"
SUPPORTED_PYTHONS="2.6 2.7 3.1"
inherit insanely-unfriendly-trickery

w/in said eclass, it does a few things

1) IUSE addition of the USE_EXPAND targets for the supported abis
2) take the enabled USE_EXPAND'd flags intersected against
SUPPORTED_PYTHON, then set deps/rdeps to
"""
python_2.6? ( pkg1[python_2.6] pkg2[python_2.6] pkg3[python2.6] )
python_2.7? ( pkg1[python_2.7] pkg2[python_2.7] pkg3[python2.7] )
python_3.1? ( pkg1[python_3.1] pkg2[python_3.1] pkg3[python3.1] )
"""

Yes, that is horrible (ciaran you knew it was going to be). Few flaws
with it also-

1) edge case when the user turns off all use flags needs addressing-
worst case, python eclass forces whatever we consider the 'default'
(aka 2.6)
2) python_2.6 isn't actually a valid use flag- it would have to be
python_2-6 or python_26 since periods aren't allowed (arfie pointed
this out)
3) this can be ugly for users if the PM doesn't treat use flags as
tristate- specifically 'explicitly-set', 'explicitly-unset',
'indeterminant'. If the ocnfiguration forces an explicit and it
conflicts w/ the use dep, ok, configuration needs to be changed. If
the use flag is indeterminant, then the PM needs to flip the flag on
it's own in that case- I know pkgcore should do this, I don't think
portage/paludis do (please correct me if wrong).


Thing to note, the deps *would* be accurate- further at the vdb level
they'd actually be usable. A dev-lang/python in the vdb is basically
unusable since implicitly the pkg that has the dep is built against
whatever slottings of python were available at the time- so if you
take a pkg from now, a year down the line when py3.2 is stabled as far
as the PM can tell that pkg *still* would work if <=py3.1 were removed
(this obviously is not true).

Note also that what I laid out above is as far as I know, going a
couple of steps beyond what the ruby eclass does (same for what the
python eclass does). I'm not necessarily advocating the approach
above, but for the raw dev-lang/python dependency we *really* should
be using use_expand there- it'll hand folk a fair amount of control as
to what abi's get installed into.

~harring
 
Old 03-19-2010, 09:34 AM
Arfrever Frehtes Taifersar Arahesis
 
Default Packages pulling in python-3*, also they dont require it

2010-03-19 11:13:48 Dale napisał(a):
> Ciaran McCreesh wrote:
> > On Fri, 19 Mar 2010 04:23:31 -0500
> > Dale<rdalek1967@gmail.com> wrote:
> >
> >>> It's being installed because it's a dependency of something you use.
> >>>
> >>> Replace Python with any other library and we wouldn't be having this
> >>> discussion.
> >>>
> >> OK. Right now, as you type this, what package depends on python-3
> >> and won't work with python-2? Anything at all? If it is nothing,
> >> then why install it?
> >>
> > And that's where you're making the mistake: you're treating Python as
> > being different from every other package.
> >
> > In every other case, you want things to be using the newest version of a
> > slotted package where possible. Why aren't you complaining that you were
> > forced to install gcc 4.3 and 4.1 when 3.4 worked just fine?
> >
> >
> Because, when I installed gcc 4.3, I could then unmerge the old gcc.
> That's why I didn't complain about that. With python, we still have to
> have the current version plus the new version which is not being used at
> all.
>
> Am I not correct in that? If the new python is installed, what exactly
> is going to use it? I used the new gcc. It worked fine. I unmerged
> the old one with no wasted space and one less package installed. This
> doesn't appear to be the case with python-3 tho. It's going to be
> installed and just sit there like a rock.

Python 3 is used during installation of packages, which support Python 2 and
Python 3 and support installation for multiple Python ABIs. You can directly
execute scripts with "-3.1" suffix (e.g. "bpython-3.1" or "coverage-3.1")
to use Python 3.1 even when Python 2.* is set as main active version of Python.

--
Arfrever Frehtes Taifersar Arahesis
 
Old 03-19-2010, 01:54 PM
Dale
 
Default Packages pulling in python-3*, also they dont require it

Arfrever Frehtes Taifersar Arahesis wrote:

2010-03-19 11:13:48 Dale napisał(a):


Ciaran McCreesh wrote:


On Fri, 19 Mar 2010 04:23:31 -0500
Dale<rdalek1967@gmail.com> wrote:



It's being installed because it's a dependency of something you use.

Replace Python with any other library and we wouldn't be having this
discussion.



OK. Right now, as you type this, what package depends on python-3
and won't work with python-2? Anything at all? If it is nothing,
then why install it?



And that's where you're making the mistake: you're treating Python as
being different from every other package.

In every other case, you want things to be using the newest version of a
slotted package where possible. Why aren't you complaining that you were
forced to install gcc 4.3 and 4.1 when 3.4 worked just fine?




Because, when I installed gcc 4.3, I could then unmerge the old gcc.
That's why I didn't complain about that. With python, we still have to
have the current version plus the new version which is not being used at
all.

Am I not correct in that? If the new python is installed, what exactly
is going to use it? I used the new gcc. It worked fine. I unmerged
the old one with no wasted space and one less package installed. This
doesn't appear to be the case with python-3 tho. It's going to be
installed and just sit there like a rock.


Python 3 is used during installation of packages, which support Python 2 and
Python 3 and support installation for multiple Python ABIs. You can directly
execute scripts with "-3.1" suffix (e.g. "bpython-3.1" or "coverage-3.1")
to use Python 3.1 even when Python 2.* is set as main active version of Python.




But again, if it will work with python2 then you don't need python3. So
you still don't need it installed just as has been said many times.


Dale

:-) :-)
 
Old 03-19-2010, 02:13 PM
Nikos Chantziaras
 
Default Packages pulling in python-3*, also they dont require it

On 03/19/2010 10:57 AM, Ciaran McCreesh wrote:

On Fri, 19 Mar 2010 03:54:28 -0500
Dale<rdalek1967@gmail.com> wrote:

Ciaran McCreesh wrote:

On Thu, 18 Mar 2010 23:17:17 +0100
Ben de Groot<yngwin@gentoo.org> wrote:


Because it is extremely useless to the great majority of users.


Most packages in the tree are useless to the great majority of
users.


Which is why most users don't install everything. I have about 1000
packages installed here. The packages installed are either something
I use or a dependency of something I use. What exactly is this being
installed for again? If nothing depends on it, there is no need to
have it.


It's being installed because it's a dependency of something you use.

Replace Python with any other library and we wouldn't be having this
discussion.


It's weird that we have this discussion, that's true. Why don't you
guys simply do what you did before when Qt3 was still in the tree? Qt3
applications depended on x11-libs/qt:3, Qt4 ones on x11-libs/qt:4
(before the Qt4 ebuild split).


It seems very obvious and straightforward that the same applies here.
And if a package offers both Python 2 and Python 3 compatibility, it
should depend on whatever the upstream of that package considers best.


Also, we had a "qt" and "qt4" USE flag before. Why not "python" and
"python3" flags? That's an additional way ebuilds can choose deps.


You guys always make easy decisions so complicated. :P
 
Old 03-19-2010, 02:21 PM
Doktor Notor
 
Default Packages pulling in python-3*, also they dont require it

On Fri, 19 Mar 2010 10:02:44 -0500
Dale <rdalek1967@gmail.com> wrote:


> Because in my opinion, portage is the first thing in line to keep a
> system sane. Installing packages that are not needed means that
> portage fails on that. So in your example, portage fails to do its
> due diligence and it falls to the users to do it for portage. Yep,
> sounds like a good idea.
>

No, portage does what the dependencies are telling it to do. I.e., if
you have unversioned dev-lang/python in DEPEND, or
>=dev-lang/python-2.4 or whatever similar then it installs
>dev-lang/python:3 - why? Because the ebuilds tell portage that it will
work like that. Another example: you have an ebuild that only works w/
gtk+-1* - you don't go to the ML asking for masking gtk+-2* but instead
go and fix the dependencies to properly reflect that. So, now you can go
and fix the dependencies treewide, or you can simply mask it *locally*
if you don't want it. You'd still need to mask it if you install
something that *really* works with both 2.x and 3.1 slots if you don't
want python-3. It's like with any other slotted stuff in the tree, but
for a reason unknown to me it's a huge issue all of a sudden because
wheeee, t3h noes, it's python.

And on that note - noone cares why people has lots of dev-libs/boost
slots installed and why's the darned thing slotted on every minor
version. So while talking about wrong dependencies, maybe the boost
maintainer could explain why do we need it slotted like this:
SLOT="$(get_version_component_range 1-2)" - simply because I'm tired of
depcleaning it all the time as nothing requires multiple slots of this
thing here.

Cheers,

DN
 
Old 03-19-2010, 11:51 PM
Duncan
 
Default Packages pulling in python-3*, also they dont require it

Dale posted on Fri, 19 Mar 2010 05:13:48 -0500 as excerpted:

> Ciaran McCreesh wrote:
>> On Fri, 19 Mar 2010 04:23:31 -0500
>> Dale<rdalek1967@gmail.com> wrote:
>>
>>>> It's being installed because it's a dependency of something you use.
>>>>
>>>> Replace Python with any other library and we wouldn't be having this
>>>> discussion.
>>>>
>>> OK. Right now, as you type this, what package depends on python-3 and
>>> won't work with python-2? Anything at all? If it is nothing, then
>>> why install it?
>>>
>> And that's where you're making the mistake: you're treating Python as
>> being different from every other package.
>>
>> In every other case, you want things to be using the newest version of
>> a slotted package where possible. Why aren't you complaining that you
>> were forced to install gcc 4.3 and 4.1 when 3.4 worked just fine?
>>
>>
> Because, when I installed gcc 4.3, I could then unmerge the old gcc.
> That's why I didn't complain about that. With python, we still have to
> have the current version plus the new version which is not being used at
> all.

I had to pick somewhere to reply, and this seemed as good a place as any,
as it does give me a jumping off point...

It seems to me Ciaran is correct in one point, at least: python-3.x /is/
different than most such major updates (but then again, each such major
update tends to have its unique points). That's why this huge discussion.

It also seems to me that, due to the resolver and dependency specifier
technology on the one side, the practicalities of running one's system
with least complication (thus, most people /not/ wanting the normal update
as soon as available/stable, in this /special/ case) on another, political
correctness (the problem with just masking it in base and being done with
it) on a third, and the number of packages to update to specific
dependencies much like portage's, should that be chosen, on the fourth,
we're pretty much surrounded with unpleasant alternatives that /are/ going
to be something of an issue for /some/, no matter which is chosen.

Again, thus the huge discussion.

So what can be done besides continuing to spin wheels as we are? What's
the least painful, yet still practical, alternative, all factors
considered?

Here's one that I'll admit isn't perfect, but none are. Yet this one
seems the best way forward to me, given the alternatives.

First, let's step back a moment and remember a defining characteristic of
Gentoo, that we give the users both freedom and responsibility for their
own systems, and have never made excuses for that fact.

Second, let's remember that we /do/ have the news feature now, so at least
there's a way to communicate a warning about such things. After that,
it's generally up to the user, as, ultimately, it seems likely to be
here. But we /can/ warn them using a news item, first, and given that,
we /should/.

So let's just recognize that it's not a perfect situation, create a news
item saying that python-3 will soon (give a date) be unmasked, and suggest
that users not needing it may wish to package.mask it themselves, with a
link to documentation with specific instructions and a bit more detail on
why they might wish to mask it and under what circumstances they might not.

I'd suggest an unmasking date 30 days after the release of the news item.

Yes, that's not going to get everyone before it happens, but the news item
will be there after that for those what want to read it, and if people
aren't doing that --ask or --pretend before they go doing their updates,
especially if they're going a month or more between updates, well...
Worst-case they get a py3k sitting there basically unused, and a few extra
builds for some period, until such time as py3k is considered stable and
popular enough to be the system default.

This to me seems the best of painful choices. Down side, it's forcing
every user to fiddle with their masks or decide not to. Three up sides:
(1) At least with the news item they get some warning and can put the mask
in place ahead of time. (2) We're simply relying on one of the best
features of Gentoo, the one giving the user both the freedom and
responsibility to manage his own system. (3) It gives us a way to
actually move forward, /now/, using our current tools, without continuing
the debate /forever/.

Can anyone shoot holes in this any worse than the other proposals? Let's
give our users the warning they need, and treat them like the adults
Gentoo has always claimed to respect them as. What they do with it after
that is up to them.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 03-20-2010, 08:56 AM
Jean-Marc Hengen
 
Default Packages pulling in python-3*, also they dont require it

Duncan wrote:
> ...

++ - I can only add the saying "With freedom comes great responsibility.".

Maybe the python herd could maintain a little status page which covers
informations like:
- Estimated python 3 compatibility in respect to the packages in the
main tree.
- Recommendations if installing makes sense or not (e.g. package X gains
feature Y with python 3).
- Recommendations if setting python 3 as system engine makes already
sense or not.
This way gentoo can give its users the tools needed to make a good
decision if python 3 makes sense on his system. For me as a user I need
more time to study if an action makes sense than implementing said
action (e.g. locally masking python 3 - It would not be the first time
masking a package). If one isn't into python, it gets even more complicated.

J_M
 
Old 03-20-2010, 11:42 AM
Nikos Chantziaras
 
Default Packages pulling in python-3*, also they dont require it

On 03/19/2010 08:26 PM, Alec Warner wrote:

On Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziaras<realnc@arcor.de> wrote:

You guys always make easy decisions so complicated. :P


Masking a package is not complicated.


Yes, that's why all the heated debates about Python 3 exist, because
it's all so simple.


It *is* simple, but you don't want it to be.
 
Old 03-20-2010, 11:47 AM
Peter Hjalmarsson
 
Default Packages pulling in python-3*, also they dont require it

fre 2010-03-19 klockan 05:13 -0500 skrev Dale:
> Because, when I installed gcc 4.3, I could then unmerge the old gcc.
> That's why I didn't complain about that. With python, we still have to
> have the current version plus the new version which is not being used at
> all.
>


That was if you did not use qemu that did *not* compile or run with a
gcc never then gcc-3 for a couple of years...

Also search for "gcc-porting" in b.g.o and guess what: there are many
packages that fits this description for gcc, qemu was just a special
case since for it it actually took YEARS before upstream released a
version that worked with gcc-4, most other packages is often easier to
patch (since it is mostly compile-time brokenness related to headers or
other "small" fixes) and our awesome toolchain guys helps fixing it up
before it hits ~arch.
 
Old 03-20-2010, 11:51 AM
Peter Hjalmarsson
 
Default Packages pulling in python-3*, also they dont require it

I have a question related to this:

If I have package X which supports python2 and python 3, and I install
it without python3 installed it will only install python2-files
(i.e. /usr/lib/python2.x/*), right?
What happens if I later install packages Y that is only python3, and
relies on the python3 parts of package X? Can this happen and how will
the PM handle that (reemerge package X installing the python3 parts or
fail to compile package Y due to missing python module)?
 

Thread Tools




All times are GMT. The time now is 02:34 AM.

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