Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Thomas Sachau to...@gentoo.org writes: Since python-3* is currently useless and not required for any package, the dependency should by default only pull in python-2* like this: =dev-lang/python-2* With that, the default way would not pull in a package, which is not needed or used. And if there will be any package, which really requires python-3*, it simply requests it in (R)DEPEND of the ebuild, which then would overwrite the default value of the eclass and pull in python-3*. That would not work. For example if package 'bar' supports both python-2 and python-3, your mechanism will only build in python-2 support. That is fine until package 'foo' comes along which uses 'bar' but also requires python-3 - thus not only must python-3 be pulled in as a result of foo's (R)DEPEND but also 'bar' must be rebuilt with python-3 support. This could be done by adding python2 and python3 USE flags to packages which support both and only have python2 enabled by default. Then 'foo' could have a conditional (R)DEPEMD on 'bar[python3]', but that would require the user to change the USE flags whereas the current system handles everything automatically.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sun, 06 Jun 2010 04:19:28 +0200 Sebastian Pipping sp...@gentoo.org wrote: Thomas, On 06/06/10 04:01, Thomas Sachau wrote: [..] so even if it is not pulled in during installation, it will be pulled in during world update. sounds right. Preventing this requires either masking or a dont-pull-uninstalled-slots switch for portage (which I am not suggesting), right? In fact, these two seem to be the most reasonable solutions for the problem. While this switch idea is more universal (and I guess -- not that hard to implement), masking should be simpler. Since python-3* is currently useless and not required for any package, the dependency should by default only pull in python-2* like this: =dev-lang/python-2* With that, the default way would not pull in a package, which is not needed or used. And if there will be any package, which really requires python-3*, it simply requests it in (R)DEPEND of the ebuild, which then would overwrite the default value of the eclass and pull in python-3*. That's an interesting idea. It sounds quite pointless to me. Forcing the packages to assume they don't support the newer version just because nothing requires it yet? Are there any reasons to pull in a package, which is not requested by the user, not required by any package and by default not used by any package? That a question I haven't seen answered before, either. Arfrever? It _is_ requested by user. User requested upgrade of all dependant packages, and here it goes. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] toolchain-funcs.eclass: functions to call compiler
On Sun, 6 Jun 2010 00:17:27 -0400 Mike Frysinger vap...@gentoo.org wrote: i'm not saying `emake` covers all solutions you proposed, just that the base usage isnt nearly as bleak. there are some cases where having a wrapper around emake would be useful (such as compiling multiple files or linking things in). so if you wanted to slap something together, we can look at it further. Well, I've already covered one corner case myself, which is the zpaq ebuild. I would approve a comment on my idea here: http://overlays.gentoo.org/proj/sunrise/changeset/10641/sunrise/app-arch/zpaq/zpaq-1.10.ebuild The hard part was that zpaq.cpp had to be compiled to both the execu- table and the stub object file (with additional -DOPT flag). I've decided that the simplest and most fail-proof idea was to create an additional source file, defining 'OPT' and including the real code, and compiling all of that within a single 'emake' call. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Am 06.06.2010 08:36, schrieb Graham Murray: Thomas Sachau to...@gentoo.org writes: Since python-3* is currently useless and not required for any package, the dependency should by default only pull in python-2* like this: =dev-lang/python-2* With that, the default way would not pull in a package, which is not needed or used. And if there will be any package, which really requires python-3*, it simply requests it in (R)DEPEND of the ebuild, which then would overwrite the default value of the eclass and pull in python-3*. That would not work. For example if package 'bar' supports both python-2 and python-3, your mechanism will only build in python-2 support. That is fine until package 'foo' comes along which uses 'bar' but also requires python-3 - thus not only must python-3 be pulled in as a result of foo's (R)DEPEND but also 'bar' must be rebuilt with python-3 support. And that is, how it should be done. Think for example of a package foo, which has a png USE flag, which will pull in libpng. By default disabled, it results in disabled png support and libpng not pulled in. Now, when some other package requires foo with png USE flag enabled, you will have to recompile foo with png USE flag and you will have to install libpng. We have the usedeps of EAPI-2 for it and the package manager does handle it, depending on the user requests. But for optional python-3 support, you cannot control it easily with your package manager because of the current way, how it is implemented. This could be done by adding python2 and python3 USE flags to packages which support both and only have python2 enabled by default. Then 'foo' could have a conditional (R)DEPEMD on 'bar[python3]', but that would require the user to change the USE flags whereas the current system handles everything automatically. And automagic behind the scene is exactly, what should not happen. The user should be able to control optional dependencies, it should be the same for python like for any other package. My base proposal for this is something like this: Every package defines the language(s), where it could be installed for multiple slots, e.g.: MULTI_SLOT=python or MULTI_SLOT=python ruby Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 By default, the current active version should be enabled, the others disabled. In addition, every dependency, which requires ruby/python should get internal usedeps, so that they require the same slots as this package. Every enabled slot should of course pull in that slot of the language. With this way, every user can select, which slots he wants to use and which slots should be installed. And if any package requires an installed version for a specific slot, it can be set in (R)DEPEND (e.g. like DEPEND= python? ( dev-db/foo[pyhon_slot_2.6] )) It would also reduce the amount of code, since we would not have to implement multi-slot support in many different eclasses and it would additionally move the dependency control back to the package manager unlike the current python implementation. I currently have a branch of portage (multilib-portage), which can install a package for different platforms, it could be extended to implement the above idea and i plan to do that. Since i am the only person working on it and me only having limited time and knowledge, it could still take some time, if noone else wants to step in and help with it. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On 06/06/2010 12:40 PM, Thomas Sachau wrote: My base proposal for this is something like this: Every package defines the language(s), where it could be installed for multiple slots, e.g.: MULTI_SLOT=python or MULTI_SLOT=python ruby Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Don't get me wrong, but isn't that what the python developers guide[1] says? (python.eclass supports PYTHON_DEPEND helper variable, which allows to specify minimal and maximal version of Python.) I thought the whole point of this debate was that nobody cared enough to convert all those ebuilds to use PYTHON_DEPEND properly. The proper fix is to convert ebuilds to the new syntax. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Michał Górny wrote: On Sun, 06 Jun 2010 04:19:28 +0200 Sebastian Pippingsp...@gentoo.org wrote: Thomas, On 06/06/10 04:01, Thomas Sachau wrote: not required by any package and by default not used by any package? That a question I haven't seen answered before, either. Arfrever? It _is_ requested by user. User requested upgrade of all dependant packages, and here it goes. So answer the last two parts of that question. I removed the rest to sort of highlight the part you missed. Dale :-) :-)
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Am 06.06.2010 09:37, schrieb Michał Górny: On Sun, 06 Jun 2010 04:19:28 +0200 Sebastian Pipping sp...@gentoo.org wrote: Thomas, On 06/06/10 04:01, Thomas Sachau wrote: Since python-3* is currently useless and not required for any package, the dependency should by default only pull in python-2* like this: =dev-lang/python-2* With that, the default way would not pull in a package, which is not needed or used. And if there will be any package, which really requires python-3*, it simply requests it in (R)DEPEND of the ebuild, which then would overwrite the default value of the eclass and pull in python-3*. That's an interesting idea. It sounds quite pointless to me. Forcing the packages to assume they don't support the newer version just because nothing requires it yet? This is not about forcing a python-2* dependency, it is just about setting a sane default. We still have many python related packages, which dont work with python-3, but i dont know of packages, which dont work with python-2. So a sane default would be to require python-2, when nothing else is set in the ebuild instead of assuming, that it works for every version including python-3. You can always overwrite this dependency in the ebuild, so you dont force anything. Are there any reasons to pull in a package, which is not requested by the user, not required by any package and by default not used by any package? That a question I haven't seen answered before, either. Arfrever? It _is_ requested by user. User requested upgrade of all dependant packages, and here it goes. Before python-3 got introduced, packages, which only support python-2, did just inherit python or distutils eclass and did not depend on python, because this dependency was in the eclass. Now with the introduction of python-3, this dependency string will introduce python-3, also those packages where not tested with python-3 and probably wont work with it. As a user, i expect a world update to update/install all needed and required packages. python-3 is neither required, nor needed or used, it is a complete optional dependency and should be handled like that, see my other mail with a possible way to handle it. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Am 06.06.2010 13:09, schrieb Matti Bickel: On 06/06/2010 12:40 PM, Thomas Sachau wrote: My base proposal for this is something like this: Every package defines the language(s), where it could be installed for multiple slots, e.g.: MULTI_SLOT=python or MULTI_SLOT=python ruby Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Don't get me wrong, but isn't that what the python developers guide[1] says? (python.eclass supports PYTHON_DEPEND helper variable, which allows to specify minimal and maximal version of Python.) I thought the whole point of this debate was that nobody cared enough to convert all those ebuilds to use PYTHON_DEPEND properly. The proper fix is to convert ebuilds to the new syntax. The current python eclass also uses some vars to specify the supported slots, yes, but it is more complex and harder to maintain in addition to the fact, that the dependency part is hidden from the package manager. I dont think, that you can tell portage with the current implementation, that it should only install python modules for python-2.6 by default and additionally python modules for python-3.1 for selected packages. Portage will also install newer slots of python, even when the user does not request them and no package requires them, which will result in unneeded and unused versions on disk. And if you add a python slot or remove one, portage currently is not able to see that and to reinstall packages, which had modules installed for that slot. You need another tool (python-updater) to check that and to call the needed reinstalls. With my solution, there are only modules installed for selected slots. And if you have selected a slot, the related python version is pulled in by portage. If you disable that slot, you can reinstall those packages with --newuse option and then can remove that python slot with --depclean. No need for another tool, simple handling by the package manager -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Le 06/06/2010 02:08, Sebastian Pipping a écrit : can you explain how that happens? Standard dependency resolution for packages with slots, there's nothing specific about python. Cheers, Rémi
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
The current python eclass also uses some vars to specify the supported slots, yes, but it is more complex and harder to maintain in addition to the fact, that the dependency part is hidden from the package manager. I dont think, that you can tell portage with the current implementation, that it should only install python modules for python-2.6 by default and additionally python modules for python-3.1 for selected packages. Portage will also install newer slots of python, even when the user does not request them and no package requires them, which will result in unneeded and unused versions on disk. Beg my pardon, but that is untrue AFAIK. Portage will install packages only for active python version, unless USE_PYTHON is set. And if you add a python slot or remove one, portage currently is not able to see that and to reinstall packages, which had modules installed for that slot. You need another tool (python-updater) to check that and to call the needed reinstalls. I agree with this fact, user should not be required to read additional documenation for portage to function as wanted. I'm very unfamiliar with inner workings of portage, but using python-updater implementation, USE_PYTHON behaviour shouldn't be that hard to implement? With my solution, there are only modules installed for selected slots. And if you have selected a slot, the related python version is pulled in by portage. If you disable that slot, you can reinstall those packages with --newuse option and then can remove that python slot with --depclean. No need for another tool, simple handling by the package manager Explicit is than implicit:) Cheers, Domen signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Am 06.06.2010 13:50, schrieb Domen Kožar: The current python eclass also uses some vars to specify the supported slots, yes, but it is more complex and harder to maintain in addition to the fact, that the dependency part is hidden from the package manager. I dont think, that you can tell portage with the current implementation, that it should only install python modules for python-2.6 by default and additionally python modules for python-3.1 for selected packages. Portage will also install newer slots of python, even when the user does not request them and no package requires them, which will result in unneeded and unused versions on disk. Beg my pardon, but that is untrue AFAIK. Portage will install packages only for active python version, unless USE_PYTHON is set. And by default, there is an active version for python-2 and an active version for python-3, which means currently an install for e.g. python:2.6 and python:3.1. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Am 06.06.2010 13:50, schrieb Domen Kožar: And if you add a python slot or remove one, portage currently is not able to see that and to reinstall packages, which had modules installed for that slot. You need another tool (python-updater) to check that and to call the needed reinstalls. I agree with this fact, user should not be required to read additional documenation for portage to function as wanted. I'm very unfamiliar with inner workings of portage, but using python-updater implementation, USE_PYTHON behaviour shouldn't be that hard to implement? You want some additional switch to portage, which does the work of python-updater? That would just move the code, but would still have the same limitations. What does speak against explicit user control for optional features/slots, including dependency handling by the package manager like in my proposal? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote: Am 06.06.2010 13:50, schrieb Domen Kožar: And if you add a python slot or remove one, portage currently is not able to see that and to reinstall packages, which had modules installed for that slot. You need another tool (python-updater) to check that and to call the needed reinstalls. I agree with this fact, user should not be required to read additional documenation for portage to function as wanted. I'm very unfamiliar with inner workings of portage, but using python-updater implementation, USE_PYTHON behaviour shouldn't be that hard to implement? You want some additional switch to portage, which does the work of python-updater? That would just move the code, but would still have the same limitations. What does speak against explicit user control for optional features/slots, including dependency handling by the package manager like in my proposal? Maybe I expressed myself wrong. Portage would only reuse python-updater to detect and repair changes with python installation. If I understand correctly, one solution would be to pull stable 2.x, and only install other slots according to USE_PYTHON. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
2010-06-06 12:40:28 Thomas Sachau napisał(a): Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 We are already working on automatic generation of USE flags in python.eclass (in newer EAPIs). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Extending EAPI=4
I would like to suggest that EAPI=4 be reopened for ability of using dots in USE flag names, which was suggested in bug #311795. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Am 06.06.2010 15:35, schrieb Domen Kožar: On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote: Am 06.06.2010 13:50, schrieb Domen Kožar: And if you add a python slot or remove one, portage currently is not able to see that and to reinstall packages, which had modules installed for that slot. You need another tool (python-updater) to check that and to call the needed reinstalls. I agree with this fact, user should not be required to read additional documenation for portage to function as wanted. I'm very unfamiliar with inner workings of portage, but using python-updater implementation, USE_PYTHON behaviour shouldn't be that hard to implement? You want some additional switch to portage, which does the work of python-updater? That would just move the code, but would still have the same limitations. What does speak against explicit user control for optional features/slots, including dependency handling by the package manager like in my proposal? Maybe I expressed myself wrong. Portage would only reuse python-updater to detect and repair changes with python installation. If I understand correctly, one solution would be to pull stable 2.x, and only install other slots according to USE_PYTHON. And how would that improve the current implementation? If you only reuse python-updater code inside portage, the issues of the current implementation still remain. And you dont seem to answer my question. Why dont you want to allow the user to control *per package*, for which slots it should be installed? And why dont you want to allow the package manager to mangle the dependency part with already existing code ( USE flags and --newuse, dependency tree and --depclean)? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Am 06.06.2010 15:44, schrieb Arfrever Frehtes Taifersar Arahesis: 2010-06-06 12:40:28 Thomas Sachau napisał(a): Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 We are already working on automatic generation of USE flags in python.eclass (in newer EAPIs). And why do you want to implement such code in every eclass? Whats wrong with implementing it on the package manager side once and reusing it for every eclass/ebuild, which needs such code? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
2010-06-06 15:54:23 Thomas Sachau napisał(a): Am 06.06.2010 15:44, schrieb Arfrever Frehtes Taifersar Arahesis: 2010-06-06 12:40:28 Thomas Sachau napisał(a): Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 We are already working on automatic generation of USE flags in python.eclass (in newer EAPIs). And why do you want to implement such code in every eclass? Whats wrong with implementing it on the package manager side once and reusing it for every eclass/ebuild, which needs such code? We can accept such an implementation if it meets all our requirements. E.g. Python ebuilds must specify list of NOT supported Python ABIs (e.g. using whitespace-separated list of fnmatch patterns). When a new slot of Python is available, then updating one place (an eclass or a file in profiles) must be sufficient to add a USE flag to all ebuilds (which don't specify a range of not supported Python ABIs which would match the new Python ABI). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sun, 2010-06-06 at 12:40 +0200, Thomas Sachau wrote: Every package defines the language(s), where it could be installed for multiple slots, e.g.: MULTI_SLOT=python or MULTI_SLOT=python ruby Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 By default, the current active version should be enabled, the others disabled. In addition, every dependency, which requires ruby/python should get internal usedeps, so that they require the same slots as this package. Every enabled slot should of course pull in that slot of the language. Something like this is already implemented for ruby. See our ruby-ng.eclass for details. Note that thinking in terms of slots here is too limiting. For ruby we currently have four targets, two of which are slotted versions of the same implementation, and two of which are independent implementations. I currently have a branch of portage (multilib-portage), which can install a package for different platforms, it could be extended to implement the above idea and i plan to do that. Since i am the only person working on it and me only having limited time and knowledge, it could still take some time, if noone else wants to step in and help with it. It might be nice to have generic support for this, especially in light of packages that have bindings in multiple languages. Please have a look at ruby-ng.eclass to see our current requirements and feel free to drop by in #gentoo-ruby for further discussion if needed. Hans signature.asc Description: This is a digitally signed message part
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-06-06 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-06-06 23h59 UTC. Removals: app-text/manedit2010-06-01 15:49:30 fuzzyray dev-java/odfdom-bin 2010-06-03 11:19:46 ali_bush app-mobilephone/openmoko-dfu-util 2010-06-05 19:25:39 vapier media-gfx/qtpfsgui 2010-06-05 20:18:18 spatz x11-misc/bbrb 2010-06-06 15:34:41 xarthisius Additions: dev-perl/Digest-MD5-File2010-05-31 09:31:44 tove x11-misc/oroborus-desklaunch2010-05-31 15:45:17 xarthisius x11-misc/oroborus-deskmenu 2010-05-31 15:49:22 xarthisius x11-misc/oroborus-keylaunch 2010-05-31 15:52:47 xarthisius dev-libs/libmelf2010-06-01 03:12:31 robbat2 kde-misc/customizable-weather 2010-06-02 23:04:29 hwoarang dev-java/jnr-x86asm 2010-06-03 09:34:50 ali_bush dev-java/jnr-posix 2010-06-03 12:23:59 ali_bush media-libs/libzen 2010-06-03 18:24:50 beandog dev-ml/ocamlgsl 2010-06-03 19:36:20 bicatali x11-misc/qsynergy 2010-06-03 19:57:42 wired media-sound/quimup 2010-06-03 20:04:11 angelos media-libs/libmediainfo 2010-06-04 02:29:16 beandog media-video/mediainfo 2010-06-04 02:43:16 beandog dev-java/jnr-netdb 2010-06-04 12:06:13 ali_bush dev-libs/pcc-libs 2010-06-04 13:03:11 patrick dev-lang/pcc2010-06-04 13:04:02 patrick media-gfx/simple-scan 2010-06-04 15:18:15 hwoarang app-cdr/gaffitter 2010-06-04 21:16:49 hwoarang sci-biology/biogrep 2010-06-04 21:59:31 hwoarang dev-java/dynalang 2010-06-05 08:24:22 ali_bush dev-vcs/topgit 2010-06-05 09:16:26 idl0r media-video/rtmpdump2010-06-05 11:07:22 hwoarang sys-fs/fuse-zip 2010-06-05 11:20:58 hwoarang net-analyzer/bwping 2010-06-05 11:52:18 hwoarang app-crypt/fcrackzip 2010-06-05 18:53:14 ssuominen app-mobilephone/dfu-util2010-06-05 19:25:17 vapier media-gfx/luminance-hdr 2010-06-05 20:15:14 spatz sci-biology/newick-utils2010-06-06 07:14:05 weaver games-board/pasang-emas 2010-06-06 07:30:50 mr_bones_ dev-perl/Package-Stash 2010-06-06 09:35:29 tove dev-perl/MooseX-Types-JSON 2010-06-06 13:52:02 tove dev-perl/MooseX-Types-Path-Class2010-06-06 13:57:09 tove media-libs/gluon2010-06-06 21:02:19 jmbsvicetto x11-themes/gartoon-redux2010-06-06 21:10:05 ssuominen -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-text/manedit,removed,fuzzyray,2010-06-01 15:49:30 dev-java/odfdom-bin,removed,ali_bush,2010-06-03 11:19:46 app-mobilephone/openmoko-dfu-util,removed,vapier,2010-06-05 19:25:39 media-gfx/qtpfsgui,removed,spatz,2010-06-05 20:18:18 x11-misc/bbrb,removed,xarthisius,2010-06-06 15:34:41 Added Packages: dev-perl/Digest-MD5-File,added,tove,2010-05-31 09:31:44 x11-misc/oroborus-desklaunch,added,xarthisius,2010-05-31 15:45:17 x11-misc/oroborus-deskmenu,added,xarthisius,2010-05-31 15:49:22 x11-misc/oroborus-keylaunch,added,xarthisius,2010-05-31 15:52:47 dev-libs/libmelf,added,robbat2,2010-06-01 03:12:31 kde-misc/customizable-weather,added,hwoarang,2010-06-02 23:04:29 dev-java/jnr-x86asm,added,ali_bush,2010-06-03 09:34:50 dev-java/jnr-posix,added,ali_bush,2010-06-03 12:23:59 media-libs/libzen,added,beandog,2010-06-03 18:24:50 dev-ml/ocamlgsl,added,bicatali,2010-06-03 19:36:20 x11-misc/qsynergy,added,wired,2010-06-03 19:57:42 media-sound/quimup,added,angelos,2010-06-03 20:04:11 media-libs/libmediainfo,added,beandog,2010-06-04 02:29:16 media-video/mediainfo,added,beandog,2010-06-04 02:43:16 dev-java/jnr-netdb,added,ali_bush,2010-06-04 12:06:13 dev-libs/pcc-libs,added,patrick,2010-06-04 13:03:11 dev-lang/pcc,added,patrick,2010-06-04 13:04:02 media-gfx/simple-scan,added,hwoarang,2010-06-04 15:18:15 app-cdr/gaffitter,added,hwoarang,2010-06-04 21:16:49 sci-biology/biogrep,added,hwoarang,2010-06-04 21:59:31 dev-java/dynalang,added,ali_bush,2010-06-05 08:24:22 dev-vcs/topgit,added,idl0r,2010-06-05 09:16:26 media-video/rtmpdump,added,hwoarang,2010-06-05 11:07:22 sys-fs/fuse-zip,added,hwoarang,2010-06-05 11:20:58 net-analyzer/bwping,added,hwoarang,2010-06-05 11:52:18 app-crypt/fcrackzip,added,ssuominen,2010-06-05 18:53:14 app-mobilephone/dfu-util,added,vapier,2010-06-05 19:25:17
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sun, Jun 06, 2010 at 01:35:55PM +, Domen Koooar wrote: On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote: Am 06.06.2010 13:50, schrieb Domen Kožar: And if you add a python slot or remove one, portage currently is not able to see that and to reinstall packages, which had modules installed for that slot. You need another tool (python-updater) to check that and to call the needed reinstalls. I agree with this fact, user should not be required to read additional documenation for portage to function as wanted. I'm very unfamiliar with inner workings of portage, but using python-updater implementation, USE_PYTHON behaviour shouldn't be that hard to implement? You want some additional switch to portage, which does the work of python-updater? That would just move the code, but would still have the same limitations. What does speak against explicit user control for optional features/slots, including dependency handling by the package manager like in my proposal? Maybe I expressed myself wrong. Portage would only reuse python-updater to detect and repair changes with python installation. If I understand correctly, one solution would be to pull stable 2.x, and only install other slots according to USE_PYTHON. $PACKAGE_MANAGER should not have to use python-updater *period*. If the USE_EXPAND route was taken for desired python versions, mapped down to virtual/python:$SLOT, the manager would know automatically of the needed python subgraph dependency wise. Really wish people would stop pointing at python-updater; it's a flat out hack that exists only due to info not being exported to the PM. ~harring pgpMvsX368M74.pgp Description: PGP signature
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sun, Jun 6, 2010 at 6:54 AM, Thomas Sachau to...@gentoo.org wrote: Am 06.06.2010 15:44, schrieb Arfrever Frehtes Taifersar Arahesis: 2010-06-06 12:40:28 Thomas Sachau napisał(a): Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=1.8 1.9 or SUPPORTED_PYTHON_SLOTS=2.5 2.6 3.0 3.1 Now the package manager should take those vars and convert them to some expanded USE vars like: RUBY_SLOTS=1.8 1.9 or PYTHON_SLOTS=2.5 2.6 3.0 3.1 We are already working on automatic generation of USE flags in python.eclass (in newer EAPIs). And why do you want to implement such code in every eclass? Whats wrong with implementing it on the package manager side once and reusing it for every eclass/ebuild, which needs such code? I don't think arfrever thinks there is anything wrong. The main problem with implementing things in a package manager is time. Why have a big long discussion about something that takes years to agree on, implement, and then get into an approved stable EAPI when you can just stick things in your eclass and use them in a few weeks / months (this can be read as a mockery of what was done; I'm not mocking. Moving quickly is important in many cases and iteration of ideas and schemes are good.) I'm all for generalizing the current implementation where it makes sense; but I'm kinda tired of people bashing it because its not perfect; I don't think we can necessarily wait for 'perfectly designed' things every time (no matter what many implementors think.) -A -- Thomas Sachau Gentoo Linux Developer
