Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On 30 June 2011 04:47, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? -mike Why can't we just split up functions.sh into /lib/output.sh containing the init script independent (but often gentoo specific) output stuff, and have functions.sh source this. Output.sh would be provided by a separate package (why not baselayout) and the packages using those would rewrite their stuff to use the right location. Paul -- Paul de Vrieze Researcher Mail: paul.devri...@gmail.com Homepage: http://www.devrieze.net
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Thu, Jun 30, 2011 at 08:58, Paul de Vrieze wrote: Why can't we just split up functions.sh into /lib/output.sh we're not changing the file name containing the init script independent (but often gentoo specific) output stuff, and have functions.sh source this. Output.sh would be provided by a separate package (why not baselayout) and the packages using those would rewrite their stuff to use the right location. we're not splitting the source trees. the reasons have already been detailed in the bug open on the topic. -mike
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Jun 30, 2011 11:06 AM, Mike Frysinger vap...@gentoo.org wrote: we're not splitting the source trees. the reasons have already been detailed in the bug open on the topic. -mike I think we're generally aiming for perfection when we should be pragmatic. The proposed solution isn't ideal, but is workable and I think that further improvement should wait until systemd/etc is mainstream (if ever). There is a similar tendency in the tags thread to aim for the revolutionary and elegant solution for everything when we basically just need some search keywords to get started... Rich
[gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
Hi all! I'm working on putting infiniband support to main tree. Currently infiniband related stuff hosted in science overlay in sys-infiniband [1] category (this category currently contains ~25 packages but they will be ~40) so i wanna move them as whole category. Also i'm going to add USE_EXPAND for infiniband userspace drivers: libmlx4 libmthca libehca libcxgb3 Any objections about moving this stuff to tree? PS some in-tree stuff already has infiniband use flag so i'd like to make it global or may be rename it to rdma [1] http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git;a=tree;f=sys- infiniband;h=5442f68fcaa8cedde34772915c605fdbab8d5541;hb=HEAD -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote: Also i'm going to add USE_EXPAND for infiniband userspace drivers: libmlx4 libmthca libehca libcxgb3 should it be based on the hardware family rather than the lib name ? Any objections about moving this stuff to tree? i object to it not being done already ! ;) -mike
Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote: On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote: Also i'm going to add USE_EXPAND for infiniband userspace drivers: libmlx4 libmthca libehca libcxgb3 use will be something like OPENIB_DRIVERS=mlx4 mthca ehca cxgb3 Honestly i can only tests first two. Also since mlx4 ib driver wants kernel with xrc support i gonna add 'cluster- sources' to tree and use flag 'xrc' to virtual/linux-sources-2.6 so sys- infiniband/libmlx4 will depend on it. So if there will be no objections i'll proceed with this stuff =) And I'll move it to tree in an hour or so. should it be based on the hardware family rather than the lib name ? Any objections about moving this stuff to tree? i object to it not being done already ! ;) -mike -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
On Thu, Jun 30, 2011 at 15:13, Alexey Shvetsov wrote: On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote: On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote: Also i'm going to add USE_EXPAND for infiniband userspace drivers: libmlx4 libmthca libehca libcxgb3 use will be something like OPENIB_DRIVERS=mlx4 mthca ehca cxgb3 Honestly i can only tests first two. i dont think that's a problem. no one is expecting you to validate every piece of hardware. -mike
Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
On Thu, Jun 30, 2011 at 10:40:26PM +0400, Alexey Shvetsov wrote: I'm working on putting infiniband support to main tree. Currently infiniband related stuff hosted in science overlay in sys-infiniband [1] category (this category currently contains ~25 packages but they will be ~40) so i wanna move them as whole category. Also i'm going to add USE_EXPAND for infiniband userspace drivers: Why a new category of sys-infiniband vs. existing sys-* categories. I thought I had seen some existing infiniband packages lurking in the tree. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
On Thursday 30 of June 2011 20:54:21 Robin H. Johnson wrote: On Thu, Jun 30, 2011 at 10:40:26PM +0400, Alexey Shvetsov wrote: I'm working on putting infiniband support to main tree. Currently infiniband related stuff hosted in science overlay in sys-infiniband [1] category (this category currently contains ~25 packages but they will be ~40) so i wanna move them as whole category. Also i'm going to add USE_EXPAND for infiniband userspace drivers: Why a new category of sys-infiniband vs. existing sys-* categories. I thought I had seen some existing infiniband packages lurking in the tree. Because its very scpecific stuff containing system libs and userspace drivers and daemons that will make ib hw functional =) -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger vap...@gentoo.org wrote: On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? Have you even heard the word called 'context'? It might be too short for your taste. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote: On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote: On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? Have you even heard the word called 'context'? It might be too short for your taste. perhaps if you focused less on being snarky and more on the thread content, you'd realize that the context here is providing /etc/init.d/functions.sh support for non-openrc users. that was the point of William's e-mail that is at the start of this current context. -mike
Re: [gentoo-dev] RFC: optinal run time dependencies
After some thinking, I'd like to re-state the USE_EXPAND variant as having the following advantages: 1) backwards compatible -- we can make the new feature optional for older EAPIs, making it useful for older ebuilds as well. If a PM doesn't support it, it will just treat them as ordinary USE; 2) almost no new learning for users -- as users set flags now, they can set optional deps; 3) dep (or dep groups) would be named by features and not only package names, 4) easy grouping of optional dependencies -- if a particular feature requires more than one optional package, 5) ability to use existing infra -- REQUIRED_USE, metadata.xml for descriptions. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Thu, 30 Jun 2011 17:16:14 -0400 Mike Frysinger vap...@gentoo.org wrote: On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote: On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote: On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? Have you even heard the word called 'context'? It might be too short for your taste. perhaps if you focused less on being snarky and more on the thread content, you'd realize that the context here is providing /etc/init.d/functions.sh support for non-openrc users. that was the point of William's e-mail that is at the start of this current context. And if you focused more on reading what others write, you'd realize that the whole citation here mentions only installing init.d scripts and /etc/runlevels? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Thu, Jun 30, 2011 at 11:30:51PM +0200, Michał Górny wrote: On Thu, 30 Jun 2011 17:16:14 -0400 Mike Frysinger vap...@gentoo.org wrote: On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote: On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote: On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? Have you even heard the word called 'context'? It might be too short for your taste. perhaps if you focused less on being snarky and more on the thread content, you'd realize that the context here is providing /etc/init.d/functions.sh support for non-openrc users. that was the point of William's e-mail that is at the start of this current context. And if you focused more on reading what others write, you'd realize that the whole citation here mentions only installing init.d scripts and /etc/runlevels? We are trying to hash out a way to make /etc/init.d/functions.sh available to all users, regardless of the init system they are using. The issue is that right now /etc/init.d/functions.sh is a symbolic link owned by OpenRC which points to /lib/rc/sh/functions.sh. Also, /lib/rc/sh/functions.sh in openrc really isn't much of a script, most of the e* functions are part of the /sbin/rc binary which is a multi call binary. We have some gentoo base functions which should be available on all gentoo systems built into the OpenRC init system. This was fine in the day when OpenRC was the only init system we used, but now it isn't fine because it is requiring everyone to have OpenRC and sysvinit installed even if they do not want to use them. I do not want to deprecate *any* gentoo base functions. I just want to make them all available in a way that does not force a dependency on OpenRC and sysvinit. The discussion on the bug has now evolved to having a separate package, gentoo-base-functions, that provides these base functions. William pgpodFV8Q0eeX.pgp Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Thu, Jun 30, 2011 at 17:30, Michał Górny wrote: On Thu, 30 Jun 2011 17:16:14 -0400 Mike Frysinger wrote: On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote: On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote: On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? Have you even heard the word called 'context'? It might be too short for your taste. perhaps if you focused less on being snarky and more on the thread content, you'd realize that the context here is providing /etc/init.d/functions.sh support for non-openrc users. that was the point of William's e-mail that is at the start of this current context. And if you focused more on reading what others write, you'd realize that the whole citation here mentions only installing init.d scripts and /etc/runlevels? umm, no. that's actually the opposite of what William said. the ultimate direction is exactly as i described, and William is hashing out different ways to get there. so yes, focus less on snarky and more on contributing something useful. -mike
[gentoo-dev] rfc: deprecation of baselayout-1.x
All, the time has come when baselayout-2.x and openrc are stable on all of our architectures. That means that we should look into removing baselayout-1 from the tree, removing support for it from our init scripts and removing support for migration from the openrc ebuilds. 1. we can remove baselayout-1 from the tree, I think, as soon as bug #368597 is closed, because once that is done, all new installs should be based on baselayout-2.x and openrc. 2. The next step is to reverse the changes we made in bug #273138 and any other init scripts that have been reacting differently depending on whether they were under baselayout-1 or openrc. Optionally we could rework init scripts to take advantage of openrc specific features such as the *_pre/post functions at this point. Once this is completed, the init scripts in portage will not support baselayout-1, so if anyone is still on baselayout-1 we should find a way to encourage them to migrate -- maybe a news item? Also, we should come up with a time window that will be published in this news item that will mark the end of supporting migration from baselayout-1 to openrc. 3. The final step is to remove the code from the openrc ebuilds that supports migrating from baselayout-1.x. Once we do this another news item should be published since this is the point of no return; anyone running a baselayout-1 based system will have to re-install to upgrade once we drop this support. Please discuss. Did I leave out any steps? Are there any points I have left out besides the time window between steps 2 and 3? Should there be a time window before removing baselayout-1? What about between steps 1 and 2? What do you consider to be a reasonable time window before we stop supporting migration from baselayout-1 to baselayout-2/openrc? I'm thinking on the order of a few months, but not years. Thanks, William pgpe1aEgTfPwn.pgp Description: PGP signature
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
William Hubbs wrote: All, the time has come when baselayout-2.x and openrc are stable on all of our architectures. That means that we should look into removing baselayout-1 from the tree, removing support for it from our init scripts and removing support for migration from the openrc ebuilds. 1. we can remove baselayout-1 from the tree, I think, as soon as bug #368597 is closed, because once that is done, all new installs should be based on baselayout-2.x and openrc. 2. The next step is to reverse the changes we made in bug #273138 and any other init scripts that have been reacting differently depending on whether they were under baselayout-1 or openrc. Optionally we could rework init scripts to take advantage of openrc specific features such as the *_pre/post functions at this point. Once this is completed, the init scripts in portage will not support baselayout-1, so if anyone is still on baselayout-1 we should find a way to encourage them to migrate -- maybe a news item? Also, we should come up with a time window that will be published in this news item that will mark the end of supporting migration from baselayout-1 to openrc. 3. The final step is to remove the code from the openrc ebuilds that supports migrating from baselayout-1.x. Once we do this another news item should be published since this is the point of no return; anyone running a baselayout-1 based system will have to re-install to upgrade once we drop this support. Please discuss. Did I leave out any steps? Are there any points I have left out besides the time window between steps 2 and 3? Should there be a time window before removing baselayout-1? What about between steps 1 and 2? What do you consider to be a reasonable time window before we stop supporting migration from baselayout-1 to baselayout-2/openrc? I'm thinking on the order of a few months, but not years. Thanks, William As a user, if a person hasn't upgraded in about 6 months, they may as well reinstall anyway. That is usually the advice given on -user. After a year without updating, it is certainly easier and most likely faster to reinstall. Almost everything will be updated and there is usually a few upgrades that are touchy and will have to be dealt with. My thoughts, after a year, baselayout1 could be laid to rest. At that point, a reinstall would be the easiest and fastest anyway. Just a users perspective. YMMV. Dale :-) :-)
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On Fri, Jul 1, 2011 at 11:03 AM, Dale rdalek1...@gmail.com wrote: William Hubbs wrote: As a user, if a person hasn't upgraded in about 6 months, they may as well reinstall anyway. That is usually the advice given on -user. After a year without updating, it is certainly easier and most likely faster to reinstall. Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
