Re: [gentoo-dev] EAPI and system packages
Le 20/09/2009 02:31, Ryan Hill a écrit : If not, when can we drop support for old EAPIs? Your opinions please. Let's drop it now. We've waited long enough. Portage with EAPI=2 has been stable for more than a year. Rémi
Re: [gentoo-dev] EAPI and system packages
On Воскресенье 20 сентября 2009 11:47:30 Rémi Cardona wrote: Le 20/09/2009 02:31, Ryan Hill a écrit : If not, when can we drop support for old EAPIs? Your opinions please. Let's drop it now. We've waited long enough. Portage with EAPI=2 has been stable for more than a year. Rémi Yes its good idea to drop EAPI2 from tree, but we should provide a way to upgrade for people that don't upgrades recently. So we can: 1 create a portage snapshot 2 write mini how to about upgrade 3 then drop EAPI=0 and EAPI=1 from tree to simplify tree -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
Alex Alexander wrote: *On Sat, Sep 19, 2009 at 23:21, Robert Bridge rob...@robbieab.com wrote: So the question isn't SHOULD python-3 be stabilised, it's what will break if it is surely? There seems to be a misunderstanding on what will happen if/when python 3 gets stabilized. The short answer is... *drum roll*... nothing :) Every Gentoo system where world or system includes deps like =dev-lang/python-2.5 will get it installed because in this case Portage will automatically update to the latest slot at least according to my quick research. I don't like putting stuff to users systems that they have no need for. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI and system packages
Ryan Hill wrote: (Yes, this has EAPI in the title, so that means everyone will chime in) I'd like to clarify and (eventually) set in stone our ideas of best practices when it comes to bumping EAPI for system packages. I was of the belief that we had decided that system packages should remain at EAPI 0 for backwards-compatibility reasons. It seems, however, that this was never written down anywhere and today we find ourselves in a situation where it is impossible to bootstrap a Gentoo system from a pre-EAPI-era liveCD due to all python versions being EAPI 1 or later. Maybe we don't care anymore, but I'd like to know what people think. I think the consensus was / is? that the upgrade path from EAPI 0 should have existed until we decide to not support it anymore and the decision should not have been made by for example python maintainers. The only packages that matter are Portage dependencies not the full system target. Basically you need to be able to upgrade your Portage and use the new version. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI and system packages
On Sun, 20 Sep 2009 13:37:46 +0300 Petteri Räty betelge...@gentoo.org wrote: Ryan Hill wrote: (Yes, this has EAPI in the title, so that means everyone will chime in) I'd like to clarify and (eventually) set in stone our ideas of best practices when it comes to bumping EAPI for system packages. I was of the belief that we had decided that system packages should remain at EAPI 0 for backwards-compatibility reasons. It seems, however, that this was never written down anywhere and today we find ourselves in a situation where it is impossible to bootstrap a Gentoo system from a pre-EAPI-era liveCD due to all python versions being EAPI 1 or later. Maybe we don't care anymore, but I'd like to know what people think. I think the consensus was / is? that the upgrade path from EAPI 0 should have existed until we decide to not support it anymore and the decision should not have been made by for example python maintainers. The only packages that matter are Portage dependencies not the full system target. Basically you need to be able to upgrade your Portage and use the new version. emerge -1O portage should still work, right? Not that I like python being EAPI0 and that kind of workarounds though... Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Stabilization of Python 3.1
Olivier Crête wrote: ~arch is for testing ebuilds, not the upstream package I'm pretty sure this isn't the case - at least not as cleanly as you suggest. Certainly testing the ebuilds themselves is part of the reason for having ~arch, but upstream readiness is part of it as well. If a package hit ~arch and we got 10 serious bugs that were all upstream problems and then somebody filed a STABLEREQ I know that I wouldn't be the one to stabilize it. The whole point of having QA is so that people who don't want to be bothered with bleeding-edge packages aren't bothered with them. Masking is for packages with known serious problems, ~arch is for packages that we think are fine but don't have much production history with, and stable is for packages that are known to be decent with history. However, I'm not convinced that the 3.1 issues need to be a showstopper for going stable. Others have made some of these suggestions, but let me consolidate some ideas that have come up: 1. A tracking bug should be created to track 3.1 stabilization issues (assuming it doesn't already exist). 2. Portage (and other system packages) deps should be checked to ensure it pulls in the current version. This should be carefully coordinated. 3. -dev-announce message sent out to check your python deps and fix them (logging blockers as needed). This need not be carefully coordinated. 4. einfo message about not eselecting the new version of python. News message as well. As long as the current version doesn't go anywhere and the current version can be re-selected at-will, then I don't see how users can get themselves into a corner. The ability to support stuff like this is the reason we have SLOTs in the first place.
Re: [gentoo-dev] EAPI and system packages
Ryan Hill wrote: So, should we always keep a working EAPI 0 version around? If not, when can we drop support for old EAPIs? Your opinions please. You might want to define what you mean by dropping support for old EAPIs? Do you mean: 1. No longer ensuring that users who have pre-EAPI versions of portage have a clean upgrade path. or 2. No longer supporting EAPI=0/1 in package managers. The former seems to be what we're talking about, but your question sounds like it is suggesting the latter. If we want to drop support for EAPI=0/1 then EVERY package in portage needs to be updated to a more recent EAPI. I suspect we're not there yet (at the very least all those system packages that are deliberately held back need to change). I can see why package managers would benefit from fewer cases to support, however...
Re: [gentoo-dev] EAPI and system packages
On Sun, 20 Sep 2009 07:28:40 -0400 Richard Freeman ri...@gentoo.org wrote: I can see why package managers would benefit from fewer cases to support, however... Doesn't make any difference to package managers. Support for old EAPIs has to remain around indefinitely to uninstall things anyway. Also, the cost's mostly in implementing a feature, which is a one-shot thing; the code that says which features are in which EAPIs is tiny. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI and system packages
On Sunday 20 September 2009 13:28:40 Richard Freeman wrote: Ryan Hill wrote: So, should we always keep a working EAPI 0 version around? If not, when can we drop support for old EAPIs? Your opinions please. You might want to define what you mean by dropping support for old EAPIs? Do you mean: 1. No longer ensuring that users who have pre-EAPI versions of portage have a clean upgrade path. or 2. No longer supporting EAPI=0/1 in package managers. I think he means neither. We should no longer tolerate pre-EAPI2 ebuilds being added to the tree and should work on migrating all old ebuilds as the need arises. Having 3+x EAPIs around (depending on how you count you can end up with twelve) makes things confusing for devs and introduces an unneeded source for accidental errors. If we want to drop support for EAPI=0/1 then EVERY package in portage needs to be updated to a more recent EAPI. I suspect we're not there yet (at the very least all those system packages that are deliberately held back need to change). It doesn't have to be a forced process. Just prevent old EAPIs from being actively used, that'll pull up most packages to a newish EAPI soon. The rest is undermaintained anyway, so if anyone feels bored he can migrate them. I can see why package managers would benefit from fewer cases to support, however... I think we should care more about developers and the tools they have instead of package manager developers and the things they may or may not do. At the same time I consider the current development of having EAPI 3 mostly finished, features for EAPI 4 discussed and ideas for EAPI 5 being thrown around to be quite stupid. The whole process needs to slow down. Most devs can't list you the differences between 0, 1 and 2 ... how do you expect them to have any benefit from adding more stuff? Just my 3 cents (inflation-corrected), Patrick
Re: [gentoo-dev] Stabilization of Python 3.1
On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org wrote: On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote: What is the point of stabilizing it if users shouldn't use it as main interpreter? Just leave it in ~arch until it can be safely used. Making it easily available so that people can port stuff, so that the entire world may be able to use it as their main interpreter sooner? Ummm, if someone is not able to keywords the ~arch package, I doubt, highly doubt, that s/he is going to be able to port anything, seriously... Just eselect set python to 3.1 and see how wonderfully your portage works... -- Jesús Guerrero
Re: [gentoo-dev] Stabilization of Python 3.1
On Sat, 19 Sep 2009 20:51:17 +0200, Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: 2009-09-19 20:22:49 Tobias Klausmann napisał(a): Hi! Aside from the remarks made by others (and speaking as someone who maintains Python software), there is one reason for me to not switch Python 3 to stable yet: lack of compatibility. Software that runs with 3.x will not run with any 2.x version as of today It's possible (and not too hard) to write code which works with Python 3 and 2.6. It might be also possible to support older versions, but it would require many ugly exec() calls etc. Possible doesn't equal to real. Most software won't work with 3.1, TODAY. -- Jesús Guerrero
Re: [gentoo-dev] Re: Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 2:42 AM, Alistair Bush ali_b...@gentoo.org wrote: Someone here want people install paludis? because when I've switched to python 3.0 just out of curiosity, it broke totally that python written package manager who is portage. So another package manager was needed to re-install a sane portage. No it wasn't. [1] You just didn't know that ( which is completely understandable ). Just as you must not have understood the implications of emerge -C python:2.6. I don't want to be mean but would you like to enlighten us as to how you managed to unemerge python:2.6 while using python3 when portage didn't work with python3. [1] http://tinderbox.dev.gentoo.org/default-linux/amd64/dev-lang/python-2.6.2- r1.tbz2 I did not unmerge python-3, I was in hard multitasking mode so I could not reconstruct how it broken so badly, also tinderbox packages work better if the CFLAGS used are the same, which is not always true. Still, do you really want to have it in tree as stable? Really? Yes really. what said in the previous message which you snipped, eselect python should forget about =python-3 is still valid IMHO
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, 20 Sep 2009 08:55:00 +1200, Alistair Bush ali_b...@gentoo.org wrote: Stabilization of Python 3.1.* will be requested at the beginning of november. There was a suggestion to create a news item which would inform users that temporarily they shouldn't switch to Python 3 as their main interpreter. Python ebuilds don't automatically activate Python 3, so I'm not sure if the news item is required. What is your opinion about it? Stablise. And to pacify all the cry babies out there could we update portage tools to call /usr/bin/python2.6 directly? Yes, we could. And *AFTER* that happens, then it will be time to *cry* ;) for the stabilization of 3.1, not now. Some people don't seem to realize that most distros are not using 3.1, and even if they were using it, Gentoo would still be a very special case because python is a core piece in this OS, and not on any other. -- Jesús Guerrero
Re: [gentoo-dev] Stabilization of Python 3.1
Richard Freeman wrote: Olivier Crête wrote: ~arch is for testing ebuilds, not the upstream package I'm pretty sure this isn't the case - at least not as cleanly as you suggest. Certainly testing the ebuilds themselves is part of the reason for having ~arch, but upstream readiness is part of it as well. If a package hit ~arch and we got 10 serious bugs that were all upstream problems and then somebody filed a STABLEREQ I know that I wouldn't be the one to stabilize it. The whole point of having QA is so that people who don't want to be bothered with bleeding-edge packages aren't bothered with them. Masking is for packages with known serious problems, ~arch is for packages that we think are fine but don't have much production history with, and stable is for packages that are known to be decent with history. However, I'm not convinced that the 3.1 issues need to be a showstopper for going stable. Others have made some of these suggestions, but let me consolidate some ideas that have come up: 1. A tracking bug should be created to track 3.1 stabilization issues (assuming it doesn't already exist). 2. Portage (and other system packages) deps should be checked to ensure it pulls in the current version. This should be carefully coordinated. 3. -dev-announce message sent out to check your python deps and fix them (logging blockers as needed). This need not be carefully coordinated. 4. einfo message about not eselecting the new version of python. News message as well. As long as the current version doesn't go anywhere and the current version can be re-selected at-will, then I don't see how users can get themselves into a corner. The ability to support stuff like this is the reason we have SLOTs in the first place. Thanks for explaining that better than I could. Dale :-) :-)
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org wrote: On Sunday 20 of September 2009 00:32:28 Dale wrote: ~arch is for testing ebuilds, not the upstream package So it would be OK to mark something stable even tho portage itself doesn't work with it? Sorry, this makes no sense to me. I run stable for the most part and having a package that portage depends on that is not stable just sounds a little like putting the cart before the horse. See some of the other replies as to why this is a not so good idea. Dale :-) :-) You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Yes? # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. That's not the usual case. In Gentoo we have a serious policy of not marking as stable things until it has passed one month without any serious bug report about it. And you are proposing to break this rule for a core piece of the OS, right, wonderful. Instead I say, first fix the stuff, and then we can start planning the switch to 3.1 -- Jesús Guerrero
Re: [gentoo-dev] Stabilization of Python 3.1
Jesús Guerrero wrote: On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org wrote: On Sunday 20 of September 2009 00:32:28 Dale wrote: ~arch is for testing ebuilds, not the upstream package So it would be OK to mark something stable even tho portage itself doesn't work with it? Sorry, this makes no sense to me. I run stable for the most part and having a package that portage depends on that is not stable just sounds a little like putting the cart before the horse. See some of the other replies as to why this is a not so good idea. Dale :-) :-) You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Yes? # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. That's not the usual case. In Gentoo we have a serious policy of not marking as stable things until it has passed one month without any serious bug report about it. And you are proposing to break this rule for a core piece of the OS, right, wonderful. Instead I say, first fix the stuff, and then we can start planning the switch to 3.1 My point exactly. No package, especially a core package that portage depends on, should just be thrown into the tree and just assume that it will work for everyone else. Dale :-) :-)
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 16:53:37 Jesús Guerrero napisał(a): On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org wrote: On Sunday 20 of September 2009 00:32:28 Dale wrote: ~arch is for testing ebuilds, not the upstream package So it would be OK to mark something stable even tho portage itself doesn't work with it? Sorry, this makes no sense to me. I run stable for the most part and having a package that portage depends on that is not stable just sounds a little like putting the cart before the horse. See some of the other replies as to why this is a not so good idea. Dale :-) :-) You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Yes? # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. I have fixed it today :) . http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. That's not the usual case. In Gentoo we have a serious policy of not marking as stable things until it has passed one month without any serious bug report about it. There wasn't any serious bug report about Python 3.1. IIRC the only problem was a (already fixed) build failure caused by non-UTF-8 characters in header of Berkeley DB. Stabilization of Python 3.1.1-r1 is planned over 1 month after its addition to the tree and about 3 months after addition of 3.1 slot to the tree. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, 20 Sep 2009 17:24:53 +0200, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-09-20 16:53:37 Jesús Guerrero napisał(a): On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org wrote: On Sunday 20 of September 2009 00:32:28 Dale wrote: ~arch is for testing ebuilds, not the upstream package So it would be OK to mark something stable even tho portage itself doesn't work with it? Sorry, this makes no sense to me. I run stable for the most part and having a package that portage depends on that is not stable just sounds a little like putting the cart before the horse. See some of the other replies as to why this is a not so good idea. Dale :-) :-) You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Yes? # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. I have fixed it today :) . http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. That's not the usual case. In Gentoo we have a serious policy of not marking as stable things until it has passed one month without any serious bug report about it. There wasn't any serious bug report about Python 3.1. IIRC the only problem was a (already fixed) build failure caused by non-UTF-8 characters in header of Berkeley DB. Stabilization of Python 3.1.1-r1 is planned over 1 month after its addition to the tree and about 3 months after addition of 3.1 slot to the tree. That sounds better. :) All users want is something that works out of the box. As long as that's true I don't have a problem with the change. I myself live in ~arch for my desktop machine, I am just concerned about the average user. -- Jesús Guerrero
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 9:16 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Are you seriously suggesting that you would knowingly break existing packages in the tree? -- ~Nirbheek Chauhan GNOME+Mozilla Team, Gentoo
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 17:56:46 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 9:16 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Are you seriously suggesting that you would knowingly break existing packages in the tree? Please stop spreading untrue information. Stabilization of Python 3 (and packages which depend on Python 3) wouldn't break any packages and wouldn't require to switch main Python interpreter to Python 3. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
On Sunday 20 September 2009, Arfrever Frehtes Taifersar Arahesis wrote: Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Of course they can. That is exactly the reason I am using a distribution (instead of LFS), because I expect maintainers of packages to coordinate and define a working set of packages for me to use. This includes holding back updates, fast-tracking updates, forward- and backward-porting. Automatisms in updates and blindly following upstream removes that extra value we are there to provide. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
Arfrever Frehtes Taifersar Arahesis wrote: 2009-09-20 16:44:09 Jesús Guerrero napisał(a): On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org wrote: On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote: What is the point of stabilizing it if users shouldn't use it as main interpreter? Just leave it in ~arch until it can be safely used. Making it easily available so that people can port stuff, so that the entire world may be able to use it as their main interpreter sooner? Ummm, if someone is not able to keywords the ~arch package, I doubt, highly doubt, that s/he is going to be able to port anything, seriously... Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Yes indeed and when you have enough apps needing Python 3, it's much easier to sell python 3 to the developer base as there's actually benefit to users. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 18:51:53 Robert Buchholz napisał(a): On Sunday 20 September 2009, Arfrever Frehtes Taifersar Arahesis wrote: Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Of course they can. That is exactly the reason I am using a distribution (instead of LFS), because I expect maintainers of packages to coordinate and define a working set of packages for me to use. This includes holding back updates, fast-tracking updates, forward- and backward-porting. Automatisms in updates and blindly following upstream removes that extra value we are there to provide. I agree. But Python 3.1 doesn't have more issues than Python 2.6, so the stabilization is reasonable. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 9:37 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: which depend on Python 3) wouldn't break any packages and wouldn't require to switch main Python interpreter to Python 3. Package X (stable) requires python-2 Package Y (stable) requires python-3 = User can't use both at the same time. You're just introducing another form of dependency hell for the users. They now have to figure out one of the following: a) Find version of Package X that works with python-3 b) Find which old version of Y still works with python-2 c) Force X/Y to use python-2/3 by patching the interpreter called d) Give up and install Ubuntu where somehow magically both work at the same time -- ~Nirbheek Chauhan GNOME+Mozilla Team, Gentoo
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 8:54 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-09-20 16:53:37 Jesús Guerrero napisał(a): # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. I have fixed it today :) . http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev This is silly. portage itself was broken with python-3.1 and you want to stabilize it? Why do you want to make it trivial for people to chop off their feet by mistake (in panic or frustration)? Actually, how did you make portage work with both 2.x and 3.x at the same time? I would be very interested to know this since afaik no useful program can work with both python-3 and python-2 with the same code. -- ~Nirbheek Chauhan GNOME+Mozilla Team, Gentoo
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 19:25:55 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 9:37 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: which depend on Python 3) wouldn't break any packages and wouldn't require to switch main Python interpreter to Python 3. Package X (stable) requires python-2 Package Y (stable) requires python-3 = User can't use both at the same time. Distribute/Setuptools will ensure that appropriate shebang is present in Python scripts. In other cases, we can easily modify shebangs in installed scripts. (A new function in python.eclass could be created for this purpose, but until now it isn't needed.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 11:05 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Package X (stable) requires python-2 Package Y (stable) requires python-3 = User can't use both at the same time. Distribute/Setuptools will ensure that appropriate shebang is present in Python scripts. In other cases, we can easily modify shebangs in installed scripts. (A new function in python.eclass could be created for this purpose, but until now it isn't needed.) Oooh, this will lead to more phun! Package A (module, stable) requires python-3 However, A is a dependency of *both* X and Y Now what? Slotting? Install to both/all python prefixes? Or some other ugly solution? Seriously, if you *really* *really* want python-3 stable, it should: 1) NOT show up in `eselect python` to set as the default interpreter 2) NOT be a dependency of any package in stable 3) Be accessibly ONLY via the name python-3 (or similar) Which means, that for stable users, it will be for personal projects only. In which case, I don't see much point in stabilizing it. -- ~Nirbheek Chauhan GNOME+Mozilla Team, Gentoo
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 19:30:54 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 8:54 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-09-20 16:53:37 Jesús Guerrero napisał(a): # eselect python set 2 # emerge -s foo File /usr/bin/emerge, line 41 except PermissionDenied, e: ^ SyntaxError: invalid syntax Ummm, yes, it works *beautifully*, you see. Nothing else to add. I have fixed it today :) . http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev This is silly. portage itself was broken with python-3.1 and you want to stabilize it? You should distinguish between Python version used by Portage and Python version used by packages which can be installed by Portage. Actually, how did you make portage work with both 2.x and 3.x at the same time? Portage doesn't yet work with Python 3, but it hopefully change soon. I would be very interested to know this since afaik no useful program can work with both python-3 and python-2 with the same code. It isn't hard to write code which works with both Python 2.6 and 3.*. Example: $ cat get_protocol.py #!/usr/bin/env python # It allows to use print() function in 2.6. from __future__ import print_function import sys try: # Python 3 from urllib.parse import urlparse as urllib_parse_urlparse except ImportError: # Python 2 from urlparse import urlparse as urllib_parse_urlparse if len(sys.argv) != 2: sys.stderr.write(This script requires 1 argument: URL\n) def get_protocol(url): return urllib_parse_urlparse(url)[0] print(Protocol:, get_protocol(sys.argv[1])) $ ./get_protocol.py http://www.example.com Protocol: http -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 19:47:28 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 11:05 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Package X (stable) requires python-2 Package Y (stable) requires python-3 = User can't use both at the same time. Distribute/Setuptools will ensure that appropriate shebang is present in Python scripts. In other cases, we can easily modify shebangs in installed scripts. (A new function in python.eclass could be created for this purpose, but until now it isn't needed.) Oooh, this will lead to more phun! Package A (module, stable) requires python-3 However, A is a dependency of *both* X and Y Now what? Slotting? Install to both/all python prefixes? Or some other ugly solution? There is a difference between Python scripts and Python modules. Python scripts should have shebang and this shebang is used to decide which interpreter should be used when './script.py' is called. But it is possible to call Python scripts using 'pythonX.Y script.py' which will enforce using of pythonX.Y instead of interpreter specified in shebang in this script. When one Python script executes another Python script (using e.g. subprocess.Popen()) then both scripts will work correctly even when they have different shebangs. Python modules shouldn't have shebang. Python modules are intended to be imported from Python scripts or other Python modules. Any shebang in a Python module is ignored, when this module is imported using 'import' statement. The chance that well known and often used Python modules start unconditionally require Python 3 in the near future is small, but Python scripts can safely do it. For example PyQt4 supports both Python 2 and 3, but a useful script, which uses PyQt4, might require Python 3. Seriously, if you *really* *really* want python-3 stable, it should: 1) NOT show up in `eselect python` to set as the default interpreter When a user wants to work for an hour with a script requiring Python 3, and doesn't want to use e.g. Portage during this time, then it is reasonable to run 'eselect python set python3.1' once and be able to just use './script.py' instead of having to type 'python3.1 script.py' every time. Next this user can switch active Python back to 2.6. 2) NOT be a dependency of any package in stable It isn't implementable without having to change dependencies in hundreds of packages. There is nothing wrong in having Python 3 installed which would use small amount of disk space. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] perl-module.class review
Attached is a diff of the current and the prospective perl-module.class.
Please review.
Thanks.
--- perl-module.eclass
+++ perl-module.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2004 Gentoo Foundation
+# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-module.eclass,v 1.116
2009/03/29 17:32:31 tove Exp $
#
@@ -13,13 +13,18 @@
# modules, and their incorporation into the Gentoo Linux system.
inherit eutils base
+[[ ${CATEGORY} == perl-core ]] inherit alternatives
+
+EXPORTED_FUNCTIONS=src_unpack src_compile src_test src_install
case ${EAPI:-0} in
0|1)
- EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm src_compile src_install src_test src_unpack
+ EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} pkg_setup pkg_preinst
pkg_postinst pkg_prerm pkg_postrm
;;
2)
- EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_install
+ EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} src_prepare
src_configure
+ [[ ${CATEGORY} == perl-core ]] \
+ EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} pkg_postinst
pkg_postrm
case ${GENTOO_DEPEND_ON_PERL:-yes} in
yes)
@@ -30,6 +35,8 @@
;;
esac
+EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
+
DESCRIPTION=Based on the $ECLASS eclass
LICENSE=${LICENSE:-|| ( Artistic GPL-2 )}
@@ -56,7 +63,7 @@
perl-module_src_unpack() {
base_src_unpack unpack
- has ${EAPI:-0} 0 1 perl-module_src_prepare
+ has src_prepare ${EXPORTED_FUNCTIONS} || perl-module_src_prepare
}
perl-module_src_prepare() {
@@ -110,7 +117,7 @@
perl-module_src_compile() {
${perlinfo_done} || perlinfo
- has ${EAPI:-0} 0 1 perl-module_src_prep
+ has src_configure ${EXPORTED_FUNCTIONS} || perl-module_src_prep
if [[ -f Build ]] ; then
./Build build \
@@ -124,13 +131,38 @@
fi
}
+# For testers:
+# This code attempts to work out your threadingness from MAKEOPTS
+# and apply them to Test::Harness.
+#
+# If you want more verbose testing, set TEST_VERBOSE=1
+# in your bashrc | /etc/make.conf | ENV
+#
+# For ebuild writers:
+# If you wish to enable default tests w/ 'make test' ,
+#
+# SRC_TEST=do
+#
+# If you wish to have threads run in parallel ( using the users makeopts )
+# all of the following have been tested to work.
+#
+# SRC_TEST=do parallel
+# SRC_TEST=parallel
+# SRC_TEST=parallel do
+# SRC_TEST=parallel
+#
+
perl-module_src_test() {
- if [[ ${SRC_TEST} == do ]] ; then
+ if has 'do' ${SRC_TEST} || has 'parallel' ${SRC_TEST} ; then
+ if has ${TEST_VERBOSE:-0} 0 has 'parallel' ${SRC_TEST} ;
then
+ export HARNESS_OPTIONS=j$(echo -j1 ${MAKEOPTS} | sed -r
s/.*(-j\s*|--jobs=)([0-9]+).*/\2/ )
+ einfo Test::Harness Jobs=${HARNESS_OPTIONS}
+ fi
${perlinfo_done} || perlinfo
if [[ -f Build ]] ; then
- ./Build test || die test failed
+ ./Build test verbose=${TEST_VERBOSE:-0} || die test
failed
elif [[ -f Makefile ]] ; then
- emake test || die test failed
+ emake test TEST_VERBOSE=${TEST_VERBOSE:-0} || die test
failed
fi
fi
}
@@ -162,7 +194,7 @@
fixlocalpod
- for f in Change* CHANGES README* ${mydoc}; do
+ for f in Change* CHANGES README* TODO ${mydoc}; do
[[ -s ${f} ]] dodoc ${f}
done
@@ -174,10 +206,12 @@
find ${D} -type f -not -name '*.so' -print0 | while read -rd '' f ; do
if file ${f} | grep -q -i text ; then
-if grep -q ${D} ${f} ; then ewarn QA: File contains a temporary path
${f} ;fi
+ grep -q ${D} ${f} ewarn QA: File contains a
temporary path ${f}
sed -i -e s:${D}:/:g ${f}
fi
done
+
+ linkduallifescripts
}
perl-module_pkg_setup() {
@@ -188,20 +222,21 @@
${perlinfo_done} || perlinfo
}
-perl-module_pkg_postinst() { : ; }
-# einfo Man pages are not installed for most modules now.
-# einfo Please use perldoc instead.
-#}
+perl-module_pkg_postinst() {
+ linkduallifescripts
+}
-perl-module_pkg_prerm() { : ; }
+perl-module_pkg_postrm() {
+ linkduallifescripts
+}
-perl-module_pkg_postrm() { : ; }
+perl-module_pkg_prerm() { : ; }
perlinfo() {
perlinfo_done=true
- local f version install{site{arch,lib},archlib,vendor{arch,lib}}
- for f in version install{site{arch,lib},archlib,vendor{arch,lib}} ; do
+ local f version install{{site,vendor}{arch,lib},archlib}
+ for f in version install{{site,vendor}{arch,lib},archlib} ; do
[gentoo-dev] perl-5.10.1 status update
Many want it - very few help. That's perl-5.10 in Gentoo. I am trying to outline the changes in the perl-experimental overlay. And if there are no objections / better ideas, that will go into the tree. After that I'll minimize my perl work if no more people join to help. So these are the changes: - sys-devel/libperl is obsolete The shared libperl.so will be installed by dev-lang/perl and perl will link it. No libperl.a will be installed. - The PDEPEND modules will be removed... As some dual-life modules (the packages in perl-core/ are also installed by perl) install scripts which would collide, currently the scripts are removed from dev-lang/perl and the package is added to PDEPEND. In 5.8.8 we have two such PDEPENDS, with 5.10 it might be ten. The problem today is, we are not able to add perl-core/Encode (#235904) without bumping dev-lang/perl. - ...and the colliding scripts will be symlinked by alternatives.eclass - perl modules must be reinstalled if any of the useflags 'ithreads' or 'debug' are changed. perl-cleaner-2 should do this correctly. For minor version bumps of perl, the script probably needs further tweaking to minimize the number of reinstalled packages. That's what i remember. http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git
Re: [gentoo-dev] EAPI and system packages
Alexey Shvetsov wrote: On Воскресенье 20 сентября 2009 11:47:30 Rémi Cardona wrote: Le 20/09/2009 02:31, Ryan Hill a écrit : If not, when can we drop support for old EAPIs? Your opinions please. Let's drop it now. We've waited long enough. Portage with EAPI=2 has been stable for more than a year. Rémi Yes its good idea to drop EAPI2 from tree, but we should provide a way to upgrade for people that don't upgrades recently. So we can: 1 create a portage snapshot 2 write mini how to about upgrade 3 then drop EAPI=0 and EAPI=1 from tree to simplify tree EAPI isn't a question of the portage so much as the packages. So long as there are no more EAPI=0 EAPI=1 ebuilds in the tree it could be discussed, though I think that removing it is 1. going to require lots of work 2. this reaps minimal benefit if it's even possible. Andrew Andrew
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: There is a difference between Python scripts and Python modules. Yes, I'm well aware of the difference between them. [snip] Python modules shouldn't have shebang. Python modules are intended to be imported from Python scripts or other Python modules. Any shebang in a Python module is ignored, when this module is imported using 'import' statement. You forget that the search path for both installs is different, and hence modules installed for python-3 cannot be found/used by scripts using python-2; which results in the dependency hell; which was the basis for my whole argument. Seriously, if you *really* *really* want python-3 stable, it should: 1) NOT show up in `eselect python` to set as the default interpreter When a user wants to work for an hour with a script requiring Python 3, and doesn't want to use e.g. Portage during this time, then it is reasonable to run 'eselect python set python3.1' once and be able to just use './script.py' instead of having to type 'python3.1 script.py' every time. Next this user can switch active Python back to 2.6. The user would rather just edit the shebang for an hour rather than become root, eselect and get back. Only us weird system-fudgers always have a root shell running, most people rarely do. 2) NOT be a dependency of any package in stable It isn't implementable without having to change dependencies in hundreds of packages. There is nothing wrong in having Python 3 installed which would use small amount of disk space. You're twisting what I mean. You know what I mean -- packages *needing* python-3. -- ~Nirbheek Chauhan GNOME+Mozilla Team, Gentoo
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 20:46:17 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: There is a difference between Python scripts and Python modules. Yes, I'm well aware of the difference between them. [snip] Python modules shouldn't have shebang. Python modules are intended to be imported from Python scripts or other Python modules. Any shebang in a Python module is ignored, when this module is imported using 'import' statement. You forget that the search path for both installs is different, and hence modules installed for python-3 cannot be found/used by scripts using python-2; These modules can be installed for both Python 2 and 3 simultaneously. Seriously, if you *really* *really* want python-3 stable, it should: ... 2) NOT be a dependency of any package in stable It isn't implementable without having to change dependencies in hundreds of packages. There is nothing wrong in having Python 3 installed which would use small amount of disk space. You're twisting what I mean. You know what I mean -- packages *needing* python-3. So Seriously, if you *really* *really* want python-3 stable, it should: ... 2) NOT be a dependency of any package in stable is already met, because no stable package unconditionally needs Python 3. If it was otherwise, then the dependency tree of these stable packages would be broken. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future
Sebastian Pipping posted on Sun, 13 Sep 2009 22:00:03 +0200 as excerpted: Duncan wrote: [L]et's get some context here. layman's no difficulty at all, really, when compared to the ordinary stuff we expect Gentoo users to do all the time. I think you forget about the learning curve: Gentoo users are not born as Gentoo users. They are coming from other distros (say Debian or Ubuntu). Not forgetting that, but perhaps forgetting how unordinary my own experience was. I came from Mandrake, but researched Gentoo well enough that I was already explaining portage basics based on the material in the Handbook, etc, on the user list (and reading the dev list), before I even had Gentoo installed. I like to think that if I can do it, everybody can, but regardless of whether they /can/ or not, it's a fact that not everybody /does/, as demonstrated by the fact that people were asking the questions I was answering. I /do/ sometimes forget /that/ end of it, that for whatever reason, not everybody chooses to read the handbook, etc, even if it's ultimately only making the job of sysadmining their own Gentoo boxen an order of magnitude harder than it should be. For me it was unmasking that confused me a lot in the beginning. There is three different kinds, one is not in the books afaik and it's no fun to me to do. I guess without autounmask by now I would be so frustrated to not use Gentoo anymore. You have me wondering now what's not in the books. I'd guess the three types of masking must be (entirely) unkeyworded, ~arch keyworded, and hard-masked (package.mask-ed), but again, unless that material has actually been /removed/ from the handbook since 2004, I was actually explaining all that to others even from my still Mandrake system, so it's /certainly/ in the books! And I don't need for autounmask, tho I do run ~arch. But the thing is, if people are running enough individual ~arch packages so handling it manually is difficult enough they need a tool for it, from my viewpoint, they should seriously consider running ~arch anyway, since stable is tested, and ~arch is somewhat tested, but nobody much tests a half-and- half system nor could it be practically so in any case since there's just too many millions of variants there to test, so trying to run such a half- and-half system is really asking for more trouble than trying to run a full ~arch system. But with a few small refinements over the years as Gentoo and its FLOSS environment have changed, again, that's very close to the same position and explanation I took from the very beginning, while I was still working on my first install. Seriously, stuff like the layman setup mess is another tiny reason keeping our user base smaller than needed, keeping our recruiting rates down. I guess I just don't see it. There's a reason the packages on the overlays aren't yet part of the tree, because in general, either the ebuilds (if not the upstream packages) aren't yet mature enough to be in- tree (at least unmasked, in-tree), or they're community ebuilds, not Gentoo-dev vetted ones. Keeping that distinction, for the protection of both Gentoo and its users, is a deliberate policy. Those who are mature enough to handle the risks of overlays can get them with little problem, while those newbies who self-evidently are NOT mature enough in their Gentoo usage to properly handle the risk (or it'd not be a problem for them in the first place since they'd be comfortable with the tools and how to use them), are by deliberate policy, kept away from the additional risk and danger. Other than minor refinements here or there, I just don't see how that can or should be changed, unless we're simply deciding that policy is wrong- headed, so damn the torpedoes headed for our users, full steam ahead, let them at 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
Re: [gentoo-dev] Stabilization of Python 3.1
Petteri Räty wrote: Every Gentoo system where world or system includes deps like =dev-lang/python-2.5 will get it installed because in this case Portage will automatically update to the latest slot at least according to my quick research. I don't like putting stuff to users systems that they have no need for. For portage-2.1.7 I'm planning to add version range detection, so ebuilds like that can use dev-lang/python-3.0 in order to prevent incompatible new versions of python from being pulled in unnecessarily. See this bug: http://bugs.gentoo.org/show_bug.cgi?id=285767 -- Thanks, Zac
Re: [gentoo-dev] Stabilization of Python 3.1
Dawid Węgliński c...@gentoo.org said: You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. And you are mixing that up. We never mark GCC stable before we fix everything we have identified as a problem, or pretty close to everything. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpW6pMGhwBsH.pgp Description: PGP signature
Re: [gentoo-dev] Stabilization of Python 3.1
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: I agree. But Python 3.1 doesn't have more issues than Python 2.6, so the stabilization is reasonable. And how about all of the packages in the tree that use python? You are missing that huge part. That's like saying libfoo works absolutely great, but every single application that links to libfoo now breaks with the new release of libfoo-2.0. The things that use your package are just as important when looking to stablize something or to move it out of package.mask. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpuYjSfPlpRR.pgp Description: PGP signature
Re: [gentoo-dev] Stabilization of Python 3.1
Mark Loeser wrote: Dawid Węgliński c...@gentoo.org said: You mix it up. Portage works with python 3.1. If an user switches to python 3.1 as the main interpreter, it's possible that his own scripts won't work. Marking it stable sometine in november give's some time to ebuilds maintainers to fix their python based apps just like it's done with gcc stabilization. And you are mixing that up. We never mark GCC stable before we fix everything we have identified as a problem, or pretty close to everything. That will be the next thing he wants to stabilize without testing. I been using Gentoo for more than 5 years and this is the first time I ever recall someone wanting to mark something stable that has not been tested for quite some time and in the normal way. Add in that this is something that portage itself depends on, this just sounds like a really bad idea. I hope someone puts a hold on this. Dale :-) :-)
[gentoo-dev] A student hopes to learn more about the Gentoo Community and the Free/Open Source Software
Dear friends, I have been reading your postings to the mailing lists of the Gentoo Community. I have really enjoyed reading about your collaborative creative activities and your perspectives on the free/open source software. My name is Tiebing Shi and I am a Ph.D. student at Queen's University in Canada. I am very interested in learning more about the Free/Open Source Software Community. The study that I am doing for my Ph.D. thesis is called User Creativity: An Investigation of the Free/Open Source Software Community. The purpose of my thesis is to study how developers and users collectively create free/open source software. I sincerely invite you to participate in my study. I would like to interview you in your role as a developer and/or user in the legendary Gentoo Community. Your experiences of developing and/or using Gentoo programs and your perspectives on the free/open source software will greatly help me to understand the creative activities of the Gentoo Community. If your time permits, I would like to interview you via phone. The phone interview will last about 1 hour. If you like, we can conduct our interview via email. Please be kindly informed that there is no obligation to participate in this study. But your participation will be highly appreciated. Your confidentiality will be protected. For example, your real name will NOT be used in my thesis and future publications. Further information about this study and our interview will be provided to you upon request. Please respond to this email to let me know your interest in participating in a phone or an email interview with me. If you select the phone interview format, please select a time for an interview that is most convenient for you. Please also let me know your phone number and time zone (my time zone is Eastern Daylight Time) so that I can call you at your local time you select. Should you have any questions, please do not hesitate to contact me. I will respond to you as soon as possible. Thank you for your support and I look forward to talking with you. Sincerely, Tiebing Shi Queen's School of Business, Queen’s University Kingston, ON, Canada K7L 3N6 Tel: 613-533-2377 (Office) Email: t...@business.queensu.ca
Re: [gentoo-dev] Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 06:20:41PM -0400, Mark Loeser wrote: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: I agree. But Python 3.1 doesn't have more issues than Python 2.6, so the stabilization is reasonable. And how about all of the packages in the tree that use python? You are missing that huge part. That's like saying libfoo works absolutely great, but every single application that links to libfoo now breaks with the new release of libfoo-2.0. The things that use your package are just as important when looking to stablize something or to move it out of package.mask. Mark pretty much nailed it on the head. Before even looking at stabilizing py3k it probably would be a good idea to identify what libs/frameworks actually *work* with it out of the box. Keep in mind that gentoo pkging of python ebuilds isn't slotted on python version- meaning you wind up with either setuptools for 2.5 or for 2.6. Then you take a look at the larger frameworks like numpy and twisted to see if they actually support 3k w/ existing releases. Not a huge number do, at least for actual releases (random branches don't count here). If the big boys don't support 3k yet, it doesn't much matter if the small fry do, thus the gain from having py3k stabilized is way less and the cost in terms of user annoyance is way larger. Regardless of the potential portage issue, I honestly don't think the state of python libs is at the point that running purely py3k w/ single slotting of python pkgs is viable. Basically what gain is there? Stabilizing it at this point comes off as whee, we have py3k stabilized! Now go mask it on all of your boxes since not a lot of the useful things play nice with it right now! My 2 cents. ~harring pgpaf2ifqTp0S.pgp Description: PGP signature
Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future
Duncan wrote: Sebastian Pipping posted on Sun, 13 Sep 2009 22:00:03 +0200 as excerpted: Duncan wrote: [L]et's get some context here. layman's no difficulty at all, really, when compared to the ordinary stuff we expect Gentoo users to do all the time. I think you forget about the learning curve: Gentoo users are not born as Gentoo users. They are coming from other distros (say Debian or Ubuntu). Not forgetting that, but perhaps forgetting how unordinary my own experience was. I came from Mandrake, but researched Gentoo well enough that I was already explaining portage basics based on the material in the Handbook, etc, on the user list (and reading the dev list), before I even had Gentoo installed. My first distro was also Mandrake. I eventually moved endlessly between Red Hat (before forking into Fedora) and Mandrake. The reason was the broken rpm package manager (and repo) which had a peculiar way of naming library .so names which interfered with my hand-built packages. I found Gentoo when a friend of mine told me there was a distro which was capable of producing CPU *optimized* code because all the packages were built from source. At the time (6~7 years ago?), I didn't have idea such distro could exist but that idea made sense and was left hard-coded in my head. That is when I read the *Gentoo philosophy* page (yes, there is people that reads it) and immediately got in love with it. That was Gentoo's biggest selling point for me. Then the handbook followed and you can probably guess the rest of the story. I like to think that if I can do it, everybody can, but regardless of whether they /can/ or not, it's a fact that not everybody /does/, as demonstrated by the fact that people were asking the questions I was answering. I think it is not a matter of capable of doing it or not but rather matching one's needs. It is also a fact that most people *don't get it* when it comes to the question *why gentoo*. I /do/ sometimes forget /that/ end of it, that for whatever reason, not everybody chooses to read the handbook, etc, even if it's ultimately only making the job of sysadmining their own Gentoo boxen an order of magnitude harder than it should be. For me it was unmasking that confused me a lot in the beginning. There is three different kinds, one is not in the books afaik and it's no fun to me to do. I guess without autounmask by now I would be so frustrated to not use Gentoo anymore. The most confusing stuff for me was to learn all the GNU/Linux basics that I had as granted while using other distros. (...) Just my 2 cents about what mattered to *me* (and still matters) when I moved to Gentoo. -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
[gentoo-dev] Last rites: dev-python/optik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have masked dev-python/optik for removal in 30 days as it is bundled with =dev-lang/python-2.4 and only needed with (And, since Python 2.3, Optik is now part of the Python standard library, under the name optparse) Best regards, [1] http://optik.sourceforge.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8) iEYEARECAAYFAkq27igACgkQdIssYB9vBoN8UwCfQ2caUrRUX6bt2+Rd5M33QGhB tAQAnjYYSvW57CxTkj8ePlfGs8Tl5ZOF =O627 -END PGP SIGNATURE-
