[gentoo-dev] Add more local USE flags
Hello, gentoo devs! I have a little story about USE flags. Almost every package in gentoo has USE flags. Many of them have clear meaning. For example: doc builds package documentation, qt or gtk build GUI frontend. Meaning of this flags is one for all packages in portage. And this is described in use.desc file. But there are many USE flags with fuzzy meaning. For example java USE flag of package net-print/cups. What does it mean? Description file says java - Adds support for Java. But what kind of support is it? Build Java bindings or build some optional tools written on Java? python flag — Adds support/bindings for the Python language also doesn't asks on my question about kind of support. Only ways to find out answer are read ebuild and ./configure --help or use other sources of information like google. But this takes time. Very very many time when installing system first time. Also this work already done by package maintainer and there is no reason to repeat this for every user. My suggestion is to take out all this per package USE flag vagueness to use.local.desc file, so you can use $ equery uses net-print/cups + + java : build java printing web-application + + python : build python bindings to libcups This is only example, I really don't know what this flags mean here. =) Another my suggestion is to extend ebuild format so package maintainer can easily add use flag description. What can you say about this? May be this is my delirium? And may be only my gentooic brain need this sort of information about USE flags.
Re: [gentoo-dev] Add more local USE flags
On 03/18/2010 02:39 PM, Dmitry Bashkatov wrote: Hello, gentoo devs! I have a little story about USE flags. Almost every package in gentoo has USE flags. Many of them have clear meaning. For example: doc builds package documentation, qt or gtk build GUI frontend. Meaning of this flags is one for all packages in portage. And this is described in use.desc file. But there are many USE flags with fuzzy meaning. For example java USE flag of package net-print/cups. What does it mean? Description file says java - Adds support for Java. But what kind of support is it? Build Java bindings or build some optional tools written on Java? python flag — Adds support/bindings for the Python language also doesn't asks on my question about kind of support. Only ways to find out answer are read ebuild and ./configure --help or use other sources of information like google. But this takes time. Very very many time when installing system first time. Also this work already done by package maintainer and there is no reason to repeat this for every user. My suggestion is to take out all this per package USE flag vagueness to use.local.desc file, so you can use $ equery uses net-print/cups + + java : build java printing web-application + + python : build python bindings to libcups This is only example, I really don't know what this flags mean here. =) Another my suggestion is to extend ebuild format so package maintainer can easily add use flag description. What can you say about this? May be this is my delirium? And may be only my gentooic brain need this sort of information about USE flags. This is already supported by metadata.xml local use flags, you can add extended information as local use flag in addition to global use flag. So I take this as a friendly reminder that maintainers should start using the feature. -Samuli
Re: [gentoo-dev] Add more local USE flags
This is already supported by metadata.xml local use flags, you can add extended information as local use flag in addition to global use flag. So I take this as a friendly reminder that maintainers should start using the feature. -Samuli It's cool! I did not know about this feature. Is there a user friendly way to read this information from metadata.xml? It seems that euse reads only use.desc and use.local.desc.
Re: [gentoo-dev] Add more local USE flags
On 03/18/2010 03:07 PM, Dmitry Bashkatov wrote: This is already supported by metadata.xml local use flags, you can add extended information as local use flag in addition to global use flag. So I take this as a friendly reminder that maintainers should start using the feature. -Samuli It's cool! I did not know about this feature. Is there a user friendly way to read this information from metadata.xml? It seems that euse reads only use.desc and use.local.desc. use.local.desc is automatically generated from metadata.xml files, so it's the same thing
Re: [gentoo-dev] Add more local USE flags
2010/3/18 Samuli Suominen ssuomi...@gentoo.org: On 03/18/2010 03:07 PM, Dmitry Bashkatov wrote: This is already supported by metadata.xml local use flags, you can add extended information as local use flag in addition to global use flag. So I take this as a friendly reminder that maintainers should start using the feature. -Samuli It's cool! I did not know about this feature. Is there a user friendly way to read this information from metadata.xml? It seems that euse reads only use.desc and use.local.desc. use.local.desc is automatically generated from metadata.xml files, so it's the same thing Thanks for your answers
Re: [gentoo-dev] Add more local USE flags
use.local.desc is automatically generated from metadata.xml files, so it's the same thing And this will soon be properly documented: http://bugs.gentoo.org/show_bug.cgi?id=309963 -- Thomas Kahle The fundamental theorem of algebra is open source. Like any other mathematical theorem it can be applied free of charge and everybody has access to its proof and can convince himself how it works. Why should software be any different? signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC]: Proxy-maintainer project
Dear fellow developers, A new project is about to start so I am requesting your feedback The primary goal of the Proxy Maintainers[1] project is to create and maintain relationships between developers and users in order to ensure packages in the Gentoo tree stay up to date. This involves a few main tasks: List Interested Developers who are interested in being Commiters. Recruit Interested Users for Proxy Maintainers. Commiter/Proxy Maintainer Training. Maintain a list of pairings between Commiters/Proxy Maintainers. Users who are willing to take care of a package will contact the developer who is interesting in the respective category. The developer and the user will work on the ebuild before they commit it to portage tree. I kinda need some feedback wrt the following topics: 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. Goals: Well, apparently the main goal is to extend what we already do on Sunrise. Pick up interesting packages without the need to maintain them actively.We will only be a proxy between portage and users. I think this is a good way to attract new developers who will get excited seeing their ebuilds going directly to portage tree, plus an excellent way to pick up important packages from the huge maintainer-wanted list which is getting bigger and bigger every day. I know there are active users who have a significant ebuild knowledge and this is a good way to enforce their skills and motivate them. Gentoo has a powerful user base and we should take advantage of it Comments? [1]http://dev.gentoo.org/~hwoarang/proxy/ -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
Hey, IMHO, [1] is not clear if you don't already know what proxy maintainance is :) 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best usually i use bugzilla at first then the good old mail vcs :) 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? maybe it'd be nice to have one, see later 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. 4) add a keyword in bugzilla for users to specify they are willing to be proxy maintainers (that's where a mail alias could be useful) Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On Thursday 18 March, Markos Chandras wrote: 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. 0) Switch portage cvs tree to multiple git ones. Sebastien
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 03/18/10 18:24, Sébastien Fabbro wrote: On Thursday 18 March, Markos Chandras wrote: 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. 0) Switch portage cvs tree to Sigh ... well, if everyone demands that ... multiple ... no, that's just silly. One tree to rule them all - we're even folding the changes from the prefix project back in. Please don't complexify things so they have enough Design ... git ones. or something equivalent
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 18/03/10 18:24, Sébastien Fabbro wrote: On Thursday 18 March, Markos Chandras wrote: 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. 0) Switch portage cvs tree to multiple git ones. I take one, too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 03/18/2010 05:29 PM, Markos Chandras wrote: Dear fellow developers, A new project is about to start so I am requesting your feedback The primary goal of the Proxy Maintainers[1] project is to create and maintain relationships between developers and users in order to ensure packages in the Gentoo tree stay up to date. This involves a few main tasks: Also it is a nice idea, i dont think, it will help Gentoo in the longer term. As i can see with the Sunrise project, most users only want to get their ebuild initially into portage/sunrise. They also listen to suggestions, improve their code and read a document to get access. But in most cases, they only do the initial commit or initial commit+some version bumps before they leave again and the ebuild is unmaintained. I dont think, we want to proxy for those users, since this would result in either the proxy maintaining the ebuilds or many more maintainer-needed ebuild in main tree. The next group of users are those, who actively maintain their ebuild, also help other users and do this for a longer time. Usually those users get a mentor offer sooner or later and then become a Gentoo Developer. So for those users, who are willing to help and can do this for longer time (requirements for Gentoo devs), sunrise is already a good starting point and base to get in. The only case, where there might be a (minimal) profit are those rare users, who initially commit their ebuild and maintain exactly and only this ebuild for a longer time. There might be 2 or 3 users doing it this way, so creating just another project for this idea is imho a bit too much work for minimal profit. I think, it might be better to send the interested users so Sunrise, where they can learn the basics and afterwards you could still offer them to proxy the ebuild (sunrise has an extra branch for proxy maintainers). A much better idea is imho to make the idea and way of Sunrise more public and easier to see without searching (Homepage, FAQ, Forums), so interested users can find it easier. In addition, every dev, who is interested in proxy maintaining something can do this via Sunrise. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages pulling in python-3*, also they dont require it
Hi, i would like to see a discussion and, if needed, a decision on the following topic: Currently, some packages just depend on dev-lang/python. Arfrever claims it to be right, but this dependency does pull in python-3*, even if the package does not require it (or does not even work with it). Since the real dep is either =dev-lang/python-2* or || ( dev-lang/python:3.1 dev-lang/python:2.7 dev-lang/python-2.6 dev-lang/python:2.5 ), it means in both cases, that my install of python-2.6* should meet the requirement, so the package should not pull in the unneeded and not used python-3*. There are 2 ways to fix this issue: -fix the dependency string for those packages (including the lines in distutils.eclass) or (since Arfrever claims current portage behaviour is wrong) -change portage behaviour to be satisfied with a python slot and to not require other slots. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 18-03-2010 20:20:02 +0100, Thomas Sachau wrote: There are 2 ways to fix this issue: -fix the dependency string for those packages (including the lines in distutils.eclass) or (since Arfrever claims current portage behaviour is wrong) -change portage behaviour to be satisfied with a python slot and to not require other slots. Since the last option will take time in any case, I guess the first option is the best to achieve the desired goal: make sure Python 3 stays as far away as possible from any system that doesn't need it. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Thu, 18 Mar 2010 20:20:02 +0100 Thomas Sachau to...@gentoo.org wrote: -change portage behaviour to be satisfied with a python slot and to not require other slots. But then you'll never get new slots for the majority of dependencies where you do usually want the newest version. If Portage were to take existing slots, most users would still be using Python 2.4 to satisfy dependencies, and would never have had 2.5+ installed... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-18 20:20:02 Thomas Sachau napisał(a): Currently, some packages just depend on dev-lang/python. Arfrever claims it to be right It's correct only for packages (e.g. dev-python/setuptools), which support all versions of Python (including Python 3). Arfrever claims current portage behaviour is wrong I claim that Portage behavior is correct. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 08:28 PM, Ciaran McCreesh wrote: On Thu, 18 Mar 2010 20:20:02 +0100 Thomas Sachau to...@gentoo.org wrote: -change portage behaviour to be satisfied with a python slot and to not require other slots. But then you'll never get new slots for the majority of dependencies where you do usually want the newest version. If Portage were to take existing slots, most users would still be using Python 2.4 to satisfy dependencies, and would never have had 2.5+ installed... I know this part, this option was just the result of Arfrever telling me that just dev-lang/python is the right dependency and the PM being wrong, when pulling in something unneeded. python-3* might be a special case, since it is incompactible with 2* versions and wont be set as the default python during install. But this results in it being useless and not needed, until either a package or a user does require it explicitly. So my vote goes for changing the dependency strings for affected packages. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 08:33 PM, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-18 20:20:02 Thomas Sachau napisał(a): Currently, some packages just depend on dev-lang/python. Arfrever claims it to be right It's correct only for packages (e.g. dev-python/setuptools), which support all versions of Python (including Python 3). Can you tell us any benefit for the normal user, when you require him to install python-3* and to install the python related packages additionally for python-3*, while the system python is still 2.6* and wont change in the near future? Arfrever claims current portage behaviour is wrong I claim that Portage behavior is correct. So you want everyone to install python-3*? See above question. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-18 20:47:35 Thomas Sachau napisał(a): On 03/18/2010 08:33 PM, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-18 20:20:02 Thomas Sachau napisał(a): Currently, some packages just depend on dev-lang/python. Arfrever claims it to be right It's correct only for packages (e.g. dev-python/setuptools), which support all versions of Python (including Python 3). Can you tell us any benefit for the normal user, when you require him to install python-3* I don't require it. It's only a side effect of correct dependencies. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 09:43 PM, Thomas Sachau wrote: So my vote goes for changing the dependency strings for affected packages. Here's some thoughts on the matter: - dev-lang/python is correct if the package works with all python versions in tree - in general we want new slots of packages like gcc being pulled in Here's how we could change Portage behavior for pulling new slots that are not strictly required: - for packages in the world file install as soon as available - for dependencies install the new slot if everything works with the new slot This would mean that Portage would stay with 2.6 as long as you have something that doesn't work with 3.x installed. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Thu, 18 Mar 2010 22:02:38 +0200 Petteri Räty betelge...@gentoo.org wrote: Here's how we could change Portage behavior for pulling new slots that are not strictly required: - for packages in the world file install as soon as available - for dependencies install the new slot if everything works with the new slot This would mean that Portage would stay with 2.6 as long as you have something that doesn't work with 3.x installed. Why would you want the majority of your packages that can use a newer, shinier version of a library to continue using the old version? Do you really want to stick with Qt3 until every single app you have supports Qt4? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 08:55 PM, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-18 20:47:35 Thomas Sachau napisał(a): On 03/18/2010 08:33 PM, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-18 20:20:02 Thomas Sachau napisał(a): Currently, some packages just depend on dev-lang/python. Arfrever claims it to be right It's correct only for packages (e.g. dev-python/setuptools), which support all versions of Python (including Python 3). Can you tell us any benefit for the normal user, when you require him to install python-3* I don't require it. It's only a side effect of correct dependencies. Wrong. Correct dependencies only require the set of packages they need, they dont pull in packages nor versions, which are not used or needed. Since you claim portage behaviour being right and you dont want to change dev-lang/python dependency, you want to force all users to install python-3*, also it is not needed nor used nor is there any benefit from it being installed. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 09:02 PM, Petteri Räty wrote: On 03/18/2010 09:43 PM, Thomas Sachau wrote: So my vote goes for changing the dependency strings for affected packages. Here's some thoughts on the matter: - dev-lang/python is correct if the package works with all python versions in tree - in general we want new slots of packages like gcc being pulled in Here's how we could change Portage behavior for pulling new slots that are not strictly required: - for packages in the world file install as soon as available - for dependencies install the new slot if everything works with the new slot This would mean that Portage would stay with 2.6 as long as you have something that doesn't work with 3.x installed. Regards, Petteri How do you detect this? Also, what about a new slot for python-2? E.g. 2.7? And do you want to add a special rule to portage just for the special case of python instead of the ebuilds/eclasses having the issue? There is currently the additional issue with distutils.eclass, which does directly add dev-lang/python to the dependencies, if there is nothing additional defined. So even e.g. dev-libs/protobuf does pull in python-3*, also there is no indication, that it will even work with that version. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 18 March 2010 20:24, Fabian Groffen grob...@gentoo.org wrote: On 18-03-2010 20:20:02 +0100, Thomas Sachau wrote: There are 2 ways to fix this issue: -fix the dependency string for those packages (including the lines in distutils.eclass) or (since Arfrever claims current portage behaviour is wrong) -change portage behaviour to be satisfied with a python slot and to not require other slots. Since the last option will take time in any case, I guess the first option is the best to achieve the desired goal: make sure Python 3 stays as far away as possible from any system that doesn't need it. And the best way to do that is to package.mask it. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On Thursday 18 March 2010 21:09:43 Thomas Sachau wrote: On 03/18/2010 05:29 PM, Markos Chandras wrote: Dear fellow developers, A new project is about to start so I am requesting your feedback The primary goal of the Proxy Maintainers[1] project is to create and maintain relationships between developers and users in order to ensure packages in the Gentoo tree stay up to date. This involves a few main tasks: Also it is a nice idea, i dont think, it will help Gentoo in the longer term. As i can see with the Sunrise project, most users only want to get their ebuild initially into portage/sunrise. They also listen to suggestions, improve their code and read a document to get access. But in most cases, they only do the initial commit or initial commit+some version bumps before they leave again and the ebuild is unmaintained. I dont think, we want to proxy for those users, since this would result in either the proxy maintaining the ebuilds or many more maintainer-needed ebuild in main tree. These users are not our target group. Our target group are highly motivated users who are willing to see their ebuilds on portage tree, they just dont know who to poke or contact us to make that happen. Some of them will be from the Sunrise userbase since we have these kind of Gentoo users there The next group of users are those, who actively maintain their ebuild, also help other users and do this for a longer time. Usually those users get a mentor offer sooner or later and then become a Gentoo Developer. Not always. I can remember at least 4 different occasions where it took them 1 year becoming a developer. Proxy-maintainer project is a good way to keep them around without pushing them completing their quizzes So for those users, who are willing to help and can do this for longer time (requirements for Gentoo devs), sunrise is already a good starting point and base to get in. Of course. But remember that we target different user group. Through this project, we intend to lower the number of maintainer-wanted packages instead of pushing them into an overlay. The difference is that, when a developer picks a package from sunrise overlay, we maintains it by himself when he puts it to portage tree. What we want to achieve here is to make users responsible for their package in portage tree. The only case, where there might be a (minimal) profit are those rare users, who initially commit their ebuild and maintain exactly and only this ebuild for a longer time. There might be 2 or 3 users doing it this way, so creating just another project for this idea is imho a bit too much work for minimal profit. Proxy-maintainer is not wide spread to users so they dont know this proxying portage ebuilds is an option. I think, it might be better to send the interested users so Sunrise, where they can learn the basics and afterwards you could still offer them to proxy the ebuild (sunrise has an extra branch for proxy maintainers). A much better idea is imho to make the idea and way of Sunrise more public and easier to see without searching (Homepage, FAQ, Forums), so interested users can find it easier. In addition, every dev, who is interested in proxy maintaining something can do this via Sunrise. Sunrise is an excellent place to train users. But we still to let them know that they can control their ebuilds on portage through us. We need to let them know what proxy-maintainer is and how to take advantage of it Are you willing to to adjust the Sunrise page accordingly? Like listing info about proxy maintainer thingie and possibly another column on the developer project table listing our areas of interest? Something like merging the two projects or extending the Sunrise one if you like -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 18 March 2010 20:09, Thomas Sachau to...@gentoo.org wrote: The next group of users are those, who actively maintain their ebuild, also help other users and do this for a longer time. Usually those users get a mentor offer sooner or later and then become a Gentoo Developer. Recruitment being the bottleneck that it is (with candidates waiting many months), it is good to have another option for people who want to contribute. In my personal experience proxy-maintenance is a good way into eventual devhood. There is no reason not to promote the possibility of proxy-maintenance. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Thu, 18 Mar 2010 21:27:50 +0100 Ben de Groot yng...@gentoo.org wrote: Since the last option will take time in any case, I guess the first option is the best to achieve the desired goal: make sure Python 3 stays as far away as possible from any system that doesn't need it. And the best way to do that is to package.mask it. Mask in the CVS tree?! Hmmm, there are tons of broken junk long dead upstream in the tree that doesn't even compile - guess what - not masked and noone's caring. Why on earth would you mask a working package with extremely active maintainer in CVS - just because you don't have a use for it? So why don't you mask it for yourself if you don't have any use for it? The time spent on this ML debate would IMHO be better spent on fixing the dependencies in the tree for stuff that doesn't work w/ python-2 and yet has unversioned or = deps in ebuilds and such. [1] Cheers, DN. [1] http://tinyurl.com/yhlmcq8 signature.asc Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 10:10 PM, Ciaran McCreesh wrote: On Thu, 18 Mar 2010 22:02:38 +0200 Petteri Räty betelge...@gentoo.org wrote: Here's how we could change Portage behavior for pulling new slots that are not strictly required: - for packages in the world file install as soon as available - for dependencies install the new slot if everything works with the new slot This would mean that Portage would stay with 2.6 as long as you have something that doesn't work with 3.x installed. Why would you want the majority of your packages that can use a newer, shinier version of a library to continue using the old version? Do you really want to stick with Qt3 until every single app you have supports Qt4? PM can make it configurable. It's a trade off between having as few packages as possible installed and upgrading as soon as possible. In general I want to keep my installed stuff to minimum. I don't have a need for new stuff that I don't know exists. If I know packages can make use of it to give me something new and shiny I can always manually request the new slot to be installed. Most likely before everything is ported over there is something written to require the new version explicitly so it's sooner than you are saying. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 18-03-2010 18:24, Sébastien Fabbro wrote: On Thursday 18 March, Markos Chandras wrote: 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. 0) Switch portage cvs tree to multiple git ones. +1 This is exactly the case where the use of repository branching makes sense. - Angelo Sebastien
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 10:21 PM, Thomas Sachau wrote: On 03/18/2010 09:02 PM, Petteri Räty wrote: On 03/18/2010 09:43 PM, Thomas Sachau wrote: So my vote goes for changing the dependency strings for affected packages. Here's some thoughts on the matter: - dev-lang/python is correct if the package works with all python versions in tree - in general we want new slots of packages like gcc being pulled in Here's how we could change Portage behavior for pulling new slots that are not strictly required: - for packages in the world file install as soon as available - for dependencies install the new slot if everything works with the new slot This would mean that Portage would stay with 2.6 as long as you have something that doesn't work with 3.x installed. Regards, Petteri How do you detect this? By looking at the dependency graph? Also, what about a new slot for python-2? E.g. 2.7? Handled by the same rules. And do you want to add a special rule to portage just for the special case of python instead of the ebuilds/eclasses having the issue? What issue is there with ebuilds/eclasses? Both should reflect the deps as well as can be done with current EAPIs. If they don't, they need to be fixed. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Thu, 18 Mar 2010 23:00:56 +0200 Petteri Räty betelge...@gentoo.org wrote: Here's how we could change Portage behavior for pulling new slots that are not strictly required: - for packages in the world file install as soon as available - for dependencies install the new slot if everything works with the new slot This would mean that Portage would stay with 2.6 as long as you have something that doesn't work with 3.x installed. How do you detect this? By looking at the dependency graph? But you can't tell whether everything will work with the new slot until you've generated a full set of decisions, and you can't generate a full set of decisions until you decide whether you want to install the newer slot. The problem with expecting the resolver to be clever is that the same kind of clever in different places leads to horrible screwups... Every time the resolver has to make some kind of decision that isn't utterly explicit it's going to do the wrong thing in an annoying minority of cases. Much better to just have ebuilds say exactly what they mean. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On Thursday 18 March 2010 23:03:37 Angelo Arrifano wrote: On 18-03-2010 18:24, Sébastien Fabbro wrote: On Thursday 18 March, Markos Chandras wrote: 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. 0) Switch portage cvs tree to multiple git ones. +1 This is exactly the case where the use of repository branching makes sense. - Angelo Sebastien Git migration may take quite a time. Recruit new developers takes a lot of time as well. So this project may help us train new developers and make them feel comfortable with gentoo internals -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Thu, Mar 18, 2010 at 09:13:01PM +0100, Thomas Sachau wrote:
On 03/18/2010 08:55 PM, Arfrever Frehtes Taifersar Arahesis wrote:
2010-03-18 20:47:35 Thomas Sachau napisał(a):
On 03/18/2010 08:33 PM, Arfrever Frehtes Taifersar Arahesis wrote:
2010-03-18 20:20:02 Thomas Sachau napisał(a):
Currently, some packages just depend on dev-lang/python. Arfrever
claims it to be right
It's correct only for packages (e.g. dev-python/setuptools), which
support all
versions of Python (including Python 3).
Can you tell us any benefit for the normal user, when you require him to
install python-3*
I don't require it. It's only a side effect of correct dependencies.
Wrong. Correct dependencies only require the set of packages they need, they
dont pull in packages
nor versions, which are not used or needed.
Since you claim portage behaviour being right and you dont want to change
dev-lang/python
dependency, you want to force all users to install python-3*, also it is not
needed nor used nor is
there any benefit from it being installed.
dev-lang/python, if the pkg supports py2k/py3k (specifically
py2.{4,5,6,7}, py3.{0,1,2}), *is* the correct dependency. End of
story, no arguement is possible on that.
Note I said 'correct', not 'desired'. It's the PM's choice how it
chooses to fullfill that constraint. Now, even if py3k is basically
unusable (for anything reliant on a framework, at this point in time
it is unusable), that *still* doesn't matter- the dependency is
*correct*.
If you want to influence how the PM chooses what to use, that's
masking or changing the algo it uses- not screwing up perfectly
correct dependencies.
Considering that the algo varies across all 3 managers, masking is the
only tool that exists atm.
~harring
pgptUvkVYB53o.pgp
Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/2010 10:00 PM, Petteri Räty wrote: And do you want to add a special rule to portage just for the special case of python instead of the ebuilds/eclasses having the issue? What issue is there with ebuilds/eclasses? Both should reflect the deps as well as can be done with current EAPIs. If they don't, they need to be fixed. Regards, Petteri I know about distutils.eclass: If an ebuild does just inherit it and does not define anything special, it will add dev-lang/python to the dependency tree, which will pull in python-3*, also noone knows, if it is requested, supported or will even work there (e.g. dev-util/protobuf does pull in python-3*, also i dont see any marks, that it does support python-3*). -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/18/10 21:53, Doktor Notor wrote: Why on earth would you mask a working package with extremely active maintainer in CVS Upstream stability is unequel Gentoo stability. Sebastian
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 18 March 2010 21:53, Doktor Notor notordok...@gmail.com wrote: On Thu, 18 Mar 2010 21:27:50 +0100 Ben de Groot yng...@gentoo.org wrote: Since the last option will take time in any case, I guess the first option is the best to achieve the desired goal: make sure Python 3 stays as far away as possible from any system that doesn't need it. And the best way to do that is to package.mask it. Mask in the CVS tree?! Hmmm, there are tons of broken junk long dead upstream in the tree that doesn't even compile - guess what - not masked and noone's caring. If that is the case, that is bad practice and should be remedied, not used as an excuse to commit more crimes. Why on earth would you mask a working package with extremely active maintainer in CVS Because it is extremely useless to the great majority of users. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] Add more local USE flags
On Thursday 18 March 2010 09:17:43 Thomas Kahle wrote: use.local.desc is automatically generated from metadata.xml files, so it's the same thing And this will soon be properly documented: http://bugs.gentoo.org/show_bug.cgi?id=309963 funny, it's in my `man portage` and has been for a while -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Thu, Mar 18, 2010 at 1:27 PM, Ben de Groot yng...@gentoo.org wrote: On 18 March 2010 20:24, Fabian Groffen grob...@gentoo.org wrote: On 18-03-2010 20:20:02 +0100, Thomas Sachau wrote: There are 2 ways to fix this issue: -fix the dependency string for those packages (including the lines in distutils.eclass) or (since Arfrever claims current portage behaviour is wrong) -change portage behaviour to be satisfied with a python slot and to not require other slots. Since the last option will take time in any case, I guess the first option is the best to achieve the desired goal: make sure Python 3 stays as far away as possible from any system that doesn't need it. And the best way to do that is to package.mask it. The maintainer has chosen not to mask it in gentoo-x86, which means users are empowered to mask it locally and everyone who is complaining about getting python3 installed on their system should mask it locally. This is how users work around other defaults in the tree they don't agree with (USE flags, KEYWORDS, etc.) I don't get why this is a big deal at all or why people are unable to solve this themselves. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-portage-dev] a feature called stabilize wanted
On Wednesday 10 March 2010 10:58:45 Johannes Kellner wrote: Hello List ans anyone! I'm searching for a feature or an hint how and where to implement it. The desired feature could be called stabilize or update to stable and would change the selected packages when doing an update (emerge -avuND world). [snip] Anyone, could help me? Give me a hint if this would be possible? Any hints where in code this could be implemented? I'm programmer, professional, so if I get the right hints, will invest spare time in this. Also I'll ready to setup and run various tests. But I never before worked at portage... It might be a good start if the people with the Know-How, will start a discussing about this idea, what problems need to be solved, which code parts will need an update and so one. Than I could try to get it working, but right now, I doesn't even know the right questions. Best regards, - Johannes Kellner At first glance your idea seems very interesting. However the versions you end up with under your system critically depends on the timing between when things go stable and when you perform an update. You could skip past a ~ version that is just about to go stable, because a newer ~ was visible, but if you'd waited just a bit longer with syncing and updating you would have gotten the stable version and no further update would have gotten you the newer ~ version. If you still wish to implement it anyway, then I would suggest that you need a new keyword modifier to indicate ``highest stable version or if that is not available the highest testing version'' and adapt the visibility code to understand that new keyword modifier and make the appropriate versions visible. I don't actually know about portage internals, but this is how I imagine it should work. Marijn
