Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. I don't like this one bit. Things used to be simple with the split between /bin and /usr/bin (and its related directories), this isn't going to make it more simple. 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I use a separate /usr with LVM on all my systems. My root partition uses RAID1. And I never had the need for an initramfs of any kind. Also, there are some major hurdles to take when it comes to getting an initramfs working with SELinux. Most initramfs implementations I saw are not SELinux aware, so all changes they make to the system either result in failures when they try, or failures when the root-switch occurs. 3) Try to maintain things the way they are as long as possible. I'm all for this one. But if people really want to focus on initramfs, I'd appreciate some documentation help on it. Not only on how to create one, but also why it is necessary, how to manage initramfs'es, the concepts underlying, etc. Wkr, Sven Vermeulen
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, Jan 1, 2012 at 2:23 PM, Sven Vermeulen sw...@gentoo.org wrote: On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. I don't like this one bit. Things used to be simple with the split between /bin and /usr/bin (and its related directories), this isn't going to make it more simple. Actually, I've always thought that the split between /usr/bin and /bin was quite arbitrary. However, I would like to note that merging /bin and /usr/bin would break some app combinations like bzip2+pbzip2, so that problem also needs to be solved (via eselect perhaps). Overall, this change feels wrong to me, but there's nothing intrinsically wrong with what they're suggesting. OTOH, it's probably just going to cause chaos and further divergence between distros for little gain. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
William Hubbs posted on Sat, 31 Dec 2011 19:59:47 -0600 as excerpted: a significant change is taking place with several upstreams that will affect us in gentoo[. Boot-critical components such as Udev, kmod, etc], are advocating a major change to the locations where binaries and libraries are stored on linux systems. The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. If we migrate everything off of the root fs to /usr, all of those solutions become moot. On the other hand, if we don't migrate, we run the risk of eventually having our default configuration not supported by upstream. I see three options: 1) Start migrating packages along with upstream[. Have separate /usr users] start using an initramfs [as previously discussed onlist]. 2) Combine the sbin and bin directories both on the root filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin. 3) Try to maintain things the way they are as long as possible. Whether or not I like what is happening personally, I think we should consider the first option, because I think it will get more and more difficult for us to do anything else over time. And we will eventually find ourselves not supported by upstreams. I'm for #1 (migrate along with upstream) as well. Gentoo has historically been both light patch, with a policy of staying close to upstream if possible, and customizer's choice, allowing users far more flexibility than most distros. Keeping both goals in mind, migrating with upstream is ultimately the only viable alternative for a whole host of reasons including both staying close to upstream and simple manpower resource issues. That said, we can continue to try to support a separate /usr as long as possible, while switching new installs to the new way and changing the handbook to document it, preferably as soon as possible. Further, as previously discussed, a near-static bare-minimal initramfs that can be configured and forgotten about for long periods over many kernel upgrades should make the switch as painless as possible at least for simple bare- partition installations. As for the switchover, I had already been thinking about it here and thus have a couple ideas I'd very much like to see implemented in portage/PM/ base.eclass that could definitely help, along with a USE flag. I'll call them migrated-rootfs and migrateroot-strict for purposes of discussion, here, and assume they're both portage features and that migrated-rootfs is also a USE flag FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr so that it'd default to ON, and would indicate that a user is an early adopter of the new layout, preferring migration as soon as possible. Users could still set the USE flag as desired for specific packages, at least at first, tho at some point it'd probably first be made a profile default, and ultimately profile-masked either on or off. Additionally, FEATURES=migrated-root would expand the collision-protect feature to check for and warn on both same-package and cross-package collisions between related dirs, with all four bin/sbin root/usr dirs checked for name collisions, and both lib dirs (for single lib, additional pairs for multilib) checked as well. Optionally, if implementation is easy enough, have portage simply remove symlinks to identically named files that would otherwise set off the warning. This is a major reason for having it a feature and a USE flag both, since if this is implemented, portage would take preventive action quite apart from whether an ebuild had been updated to use the USE flag or not. FEATURES=migrateroot-strict would make those collision warnings fatal, much like FEATURES=multilib-strict does for its multilib checks. (As an amd64 user who had this feature on for years, until I switched to no- multilib, that's what the idea is based on.) The goal would be to allow early adopter users to set the less strict version and run a --empty-tree @world update, then grep the logs for the warnings it turned on. If none occurred and /usr is either already on the same filesystem or they have the appropriate early-boot measures in place, they could feel reasonably confident about setting up symlinks pointing to the /usr/bin and /usr/lib dirs as appropriate, and could then set FEATURES=migratedroot-strict to ensure it stays clean, since after that any attempted merge that would collide would be fatal. Alternatively users could just set the strict version and see what breaks, instead of grepping the logs for the warnings. Since this would leverage the code already in place and tested for collision-protect and multilib-strict, cross-package checking should be fairly easy to implement, but same-package checking and/or
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Sven Vermeulen wrote: But if people really want to focus on initramfs, I'd appreciate some documentation help on it. Not only on how to create one, but also why it is necessary, how to manage initramfs'es, the concepts underlying, etc. Wkr, Sven Vermeulen This is my issue as well. I tried to make a init* to deal with this and have yet to get one to work, not one single working boot up. I have tried different howtos and not one of them produced anything that works. I have not found a dracut howto that makes any sense either. Sorry but genkernel left a bad taste in my mouth ages ago. As bad as I hate to even use a init*, I hate even worse being told I have to have one and not being able to get one to work following the docs. There needs to be some really well tested docs for people to use before this kicks in. Now to go brush my teeth. :/ This init* thingy tastes really bad. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On 01/01/2012 01:23 AM, Duncan wrote: As for the switchover, I had already been thinking about it here and thus have a couple ideas I'd very much like to see implemented in portage/PM/ base.eclass that could definitely help, along with a USE flag. I'll call them migrated-rootfs and migrateroot-strict for purposes of discussion, here, and assume they're both portage features and that migrated-rootfs is also a USE flag FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr so that it'd default to ON, and would indicate that a user is an early adopter of the new layout, preferring migration as soon as possible. Users could still set the USE flag as desired for specific packages, at least at first, tho at some point it'd probably first be made a profile default, and ultimately profile-masked either on or off. I'm not sure if a USE flag for FEATURES setting would be necessary. If we want to enforce a global policy, then I guess a QA warning would be warranted. Overall, a migration like this should go pretty smoothly as long as people with separate /usr take appropriate actions to make sure their systems will boot. People without separate /usr can basically relax and enjoy the ride. -- Thanks, Zac
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, Jan 1, 2012 at 4:45 AM, Dale rdalek1...@gmail.com wrote: This is my issue as well. I tried to make a init* to deal with this and have yet to get one to work, not one single working boot up. I have tried different howtos and not one of them produced anything that works. I have not found a dracut howto that makes any sense either. Sorry but genkernel left a bad taste in my mouth ages ago. While I think that the direction we're moving in (/usr on root or use an initramfs) is inevitable, I do agree that it needs some improvement. I've gotten Dracut to work fine in VMs (even with fairly complex setups), but every time I try it on my server it doesn't set up the raid for some reason, and drops me to a dash shell. If I just run mdadm_auto at that point it takes about 15 seconds to find and setup my raid, and just typing exit boots the system just fine. I keep it as an option in grub so that whenever my raid device numbers get mixed up (seems to happen every other month for no apparent reason) I can boot the system, since dracut does use the mdadm.conf and UUIDs to put everything in the right place and find the right root (something you can't do without an initramfs). One of these days I'll figure out how to hack an mdadm_auto into the script as a last-ditch measure and then I'll just have to deal with a one-minute delay. For being the wave of the future it seems like the only documentation Dracut has is a single page website with a few paragraphs of info. I think the bottom line is that the future may look inevitable, but it isn't actually here yet. I advocate being ready for the future, but let's try not to force its arrival before everything is mature (though having it in portage as an option is completely in the spirit of Gentoo). Rich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Rich Freeman wrote: On Sun, Jan 1, 2012 at 4:45 AM, Dalerdalek1...@gmail.com wrote: This is my issue as well. I tried to make a init* to deal with this and have yet to get one to work, not one single working boot up. I have tried different howtos and not one of them produced anything that works. I have not found a dracut howto that makes any sense either. Sorry but genkernel left a bad taste in my mouth ages ago. While I think that the direction we're moving in (/usr on root or use an initramfs) is inevitable, I do agree that it needs some improvement. I've gotten Dracut to work fine in VMs (even with fairly complex setups), but every time I try it on my server it doesn't set up the raid for some reason, and drops me to a dash shell. If I just run mdadm_auto at that point it takes about 15 seconds to find and setup my raid, and just typing exit boots the system just fine. I keep it as an option in grub so that whenever my raid device numbers get mixed up (seems to happen every other month for no apparent reason) I can boot the system, since dracut does use the mdadm.conf and UUIDs to put everything in the right place and find the right root (something you can't do without an initramfs). One of these days I'll figure out how to hack an mdadm_auto into the script as a last-ditch measure and then I'll just have to deal with a one-minute delay. For being the wave of the future it seems like the only documentation Dracut has is a single page website with a few paragraphs of info. I think the bottom line is that the future may look inevitable, but it isn't actually here yet. I advocate being ready for the future, but let's try not to force its arrival before everything is mature (though having it in portage as an option is completely in the spirit of Gentoo). Rich I installed dracut and it did something, although I'm not sure what yet. I googled until I think google should be tired of me to find docs to help. Getting it to run was on one page, then figuring out some options was on yet another page, then grub was on yet another. I don't know yet if some of these are outdated or anything so I don't know if it is going to work or just blow up something. Please, don't ask me what it did. I said I did it, I didn't say I understand it. If it is broken or breaks in the future, I'm screwed. (Sort of starting to wonder why I left Mandriva now. I could have swore I wanted to be rid of init* stuff and make my on freakin kernels. ) I might also add for those considering dracut being the official way, it is keyworded at this point. I would think someone needs to get this stable or whatever needs doing before telling folks to use this. It may work fine but if that is the case, then it needs to be unkeyworded. Spell check doesn't like our terms here. I think the future is actually taking several steps backward. That point has been discussed to death tho. I hope Sven has his thinking hat on. Maybe I can help some with the docs. If it works for me, it should work for most. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, Jan 01, 2012 at 02:12:22AM -0500, Olivier Crête wrote: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I also don't see a good reason to not adopt dracut, re-implementing something that already works and is maintained by a competent upstream seems wasteful to me. I really don't see why people resist using an initramfs so much. The udev/kmod/systemd/dracut effort to standardise the base userspace of Linux is probably scary for quite a few Gentoo-ers as it means that the end result of an installed Gentoo system will be less differentiated than it was before. But it still is a step in the right direction as most of these standardized pieces are much better than what we currently have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and unmaintained upstream shows that even a relatively large distribution like us can't maintain a competitive base system solution, adopting the udev/kmod/systemd way will allow us to use all the work that they are doing and instead concentrate on making a better system. The problem you are missing here is that gentoo isn't just for linux. We are cross-platform, so we have to have a cross-platform init system as the default. Unless they port systemd to *bsd, we may have to keep openrc as the default init system for some time afaik. Also, your statement about openrc not being maintained upstream is not correct. It is correct that Roy doesn't work on it any more, but there is a team that does maintain it. William pgp6gXRfCFU9h.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, 31 Dec 2011 19:59:47 -0600 William Hubbs willi...@gentoo.org wrote: I see three options: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. 2) Combine the sbin and bin directories both on the root filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin. 3) Try to maintain things the way they are as long as possible. We should *at least* start doing some preparations, like ensuring that random things don't unnecessarily hardcode /sbin or /bin paths. Most importantly, if a particular tool runs in a complete environment (which is true for most of the cases), there is no need to hardcode paths to tools. As I see it, 2) seems achievable within a reasonable time now. It shouldn't require any specific changes from users (except for fixing their own broken scripts) yet some tree-wide action of fixing hardcoded paths. We could create /sbin and /usr/sbin symlinks as well but that shouldn't be really necessary, especially if we prepare packages well beforehand. Introducing such symlinks would be hard to perform and getting rid of them later would be even harder; mostly due to PMS-enforced limitations. For a long-term view, 1) is the only way to go. Splitting packages randomly between rootfs and /usr was never really correct, and we especially shouldn't force users to junk their systems with shattered packages and cheap glue to keep it all working. I'd suggest going the other way than I did with kmod. Temporary IUSE like 'install-to-usr', disabled by default for now. Packages having that IUSE should have correct USE-dependencies, and users who need not to use that could just enable 'install-to-usr' globally (we'd probably want to mask it first). Of course, that way will require removing hardcoded paths as well, or supporting switching them on IUSE. For the latter, it may be simpler to use '[install-to-usr=]' kind of dependencies. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Zac Medico posted on Sun, 01 Jan 2012 02:15:49 -0800 as excerpted: I'm not sure if a USE flag for FEATURES setting would be necessary. If we want to enforce a global policy, then I guess a QA warning would be warranted. I didn't state why I suggested that, but here's the reasoning: Unless I missed an update somewhere, USE flags are covered by PMS and thus available to be used in ebuilds, etc. AFAIK, portage FEATURES are just that, portage FEATURES, and thus are supposed to be opaque to ebuilds, which shouldn't need to care which PM is running or its features, as long as it's PMS compliant. Thus, the split between the FEATURES bit which the ebuild shouldn't need to know about (the user sets up the symlinks and sets the features and portage takes care of it managing the rest for existing versions without rewriting), and the USE flag, for where upstreams and/or ebuilds are actually rewritten with the possibility of both layouts (and later only the /usr locations) in mind and the ebuild installs to the targeted location based on the USE flag. -- 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] Re: rfc: locations of binaries and separate /usr
On Sun, Jan 01, 2012 at 09:23:11AM +, Duncan wrote: Gentoo has historically been both light patch, with a policy of staying close to upstream if possible, and customizer's choice, allowing users far more flexibility than most distros. Keeping both goals in mind, migrating with upstream is ultimately the only viable alternative for a whole host of reasons including both staying close to upstream and simple manpower resource issues. That said, we can continue to try to support a separate /usr as long as possible, while switching new installs to the new way and changing the handbook to document it, preferably as soon as possible. In this situation, I don't know how we will be able to support both ways because there is more involved than just where things are installed. Udev 175 is currently masked, because the way it operates has changed enough that it doesn't work correctly if it starts before /usr is mounted, and the failures you find will be very difficult to track down. So, udev isn't only changing where it is installed, but how it runs. Supporting a separate /usr without an initramfs will require one of two things. One possibility is a customization to openrc, which we have been looking at, that would be able to run fsck on /usr and mount /usr all before udev starts. The drawback here is this will only work for openrc users. Another possibility is a script that would run as the init= parameter to the kernel, which would fsck /usr and mount /usr then start the real init process. This would be more generic and would be able to run regardless of whether you are using sysvinit/openrc. Here is the big problem with both of these solutions as I see them. They depend on several pieces of software remaining on the root filesystem, and if/when this software is migrated, we will be back to having this discussion again. Further, as previously discussed, a near-static bare-minimal initramfs that can be configured and forgotten about for long periods over many kernel upgrades should make the switch as painless as possible at least for simple bare- partition installations. I want to look at dracut and see if there is a way to configure it to create a minimal initramfs like you are suggesting, because, if there is we don't need to re-invent the wheel. I don't think your portage feature/use flag suggestion is a good idea, because, right now most of this is about where things are installed, but, eventually we might have to start actually patching software to make it work if it is installed on / instead of /usr, and there is no way to know how much patching we would have to do. What are your thoughts? William pgpDjsJWmAho1.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crête tes...@gentoo.org wrote: The udev/kmod/systemd/dracut effort to standardise the base userspace of Linux is probably scary for quite a few Gentoo-ers as it means that the end result of an installed Gentoo system will be less differentiated than it was before. But it still is a step in the right direction as most of these standardized pieces are much better than what we currently have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and unmaintained upstream shows that even a relatively large distribution like us can't maintain a competitive base system solution, adopting the udev/kmod/systemd way will allow us to use all the work that they are doing and instead concentrate on making a better system. Doesn't all this mess just show that no-one else can maintain a competitive base system solution either? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
Yeah I know Im replying to my own message, but I wanted to add a
thought about the symbolic links issue.
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
That way, once the package maintainer knows that the symbolic links are
not needed, they can be removed and eventually all of these directories
would be empty and they could eventually be removed if desired.
Thoughts?
William
pgp7ofExXW7iu.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: news item for app-backup/bacula
On Sat, 31 Dec 2011 08:56:03 -0600 William Hubbs willi...@gentoo.org wrote: On Fri, Dec 30, 2011 at 10:11:58AM +0100, Michał Górny wrote: On Fri, 30 Dec 2011 09:56:33 +0100 Thomas Beierlein tom...@gentoo.org wrote: The 5.2.x release series of Bacula uses a new database catalog format. ^^^ use (singular) No, uses is correct here. OK. Thanks for the hint. I will change it back to 'uses'. Thomas William -- signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote: On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crête tes...@gentoo.org wrote: All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. That's why you have dracut to do it for you. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 1 Jan 2012 01:33:05 -0600 Matthew Thode (prometheanfire) prometheanf...@gentoo.org wrote: All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. Eh, I think I'll end up writing myself that four lines of shell code for you which mounts /usr and runs init. Or maybe I'll leave that task to you. Attaching my /init for micro-initramfs on klibc. It looks like that: ├── bin │ ├── ls │ ├── mount │ ├── run-init │ └── sh ├── dev │ ├── null │ └── sda2 ├── init ├── lib64 │ ├── klibc-MZ_9MGQEe6NFqmrPjRpy5i6WlV8.so │ └── libc.so - klibc-MZ_9MGQEe6NFqmrPjRpy5i6WlV8.so ├── newroot └── proc $ du -sh 176K. -- Best regards, Michał Górny init Description: Binary data signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
Hi,
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 15:33 +0800, Patrick Lauer wrote: On 01/01/12 15:12, Olivier Crête wrote: Hi, On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: I have been working with robbat2 on solutions to the separate /usr issue (That is why I have specifically cc'd him on this email) which will allow people to not use an initramfs. If we migrate everything off of the root fs to /usr, all of those solutions become moot. On the other hand, if we don't migrate, we run the risk of eventually having our default configuration not supported by upstream. I think the general consensus among other distros is that initramfs is the new /. Many core elements of the Linux system will start installing themselves in /usr, starting with udev, so we won't have a choice anyway. Also, I doubt it's currently possible to boot a Gentoo system without /usr mounted anyway. initramfs is the new / ... and no one asked if maybe that doesn't really make sense? That people are now actively working on forcing one big system partition is annoying, but I really don't see the need to add a layer or two of complexification just because, well, why not. We're absolutely not forcing a single system partition. We're just saying that the bits required to mount all the partitions you want should be in an initramfs. 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I also don't see a good reason to not adopt dracut, Make it work and I'll reconsider it, until then genkernel wins by default. re-implementing something that already works and is maintained by a competent upstream seems wasteful to me. I really don't see why people resist using an initramfs so much. What does it add, apart from time to the boot process? For some setups (like my notebook with luks+lvm) there's no reasonable way around it, but on my desktop it's worse than useless. I don't see how it adds time to the boot process. Either you have a single big partition (and then you don't even need an initramfs), or you have multiple partitions and then most of the time is mounting them anyway. The udev/kmod/systemd/dracut effort to standardise the base userspace of Linux is probably scary for quite a few Gentoo-ers as it means that the end result of an installed Gentoo system will be less differentiated than it was before. But it still is a step in the right direction as most of these standardized pieces are much better than what we currently have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and unmaintained upstream shows that even a relatively large distribution like us can't maintain a competitive base system solution, Eh what? I don't see an advantage in replacing a known-good solution with some random stuff that mostly doesn't work yet just because it's the future. Random stuff that was well though to work together and works well enough that all other major distros are adopting it. adopting the udev/kmod/systemd way will allow us to use all the work that they are doing and instead concentrate on making a better system. Better means no lennartware to me. I want to be able to fully debug init script failures, which systemd makes very hard to impossible. On some machines I have changes in the startup that would mean having to hack up something in C and hope that it doesn't crash init for systemd (what the blp?) You can start services with a shell scripts in systemd, you just have to aim the .service unit file to you shellscript.. Please don't try to bring the GnomeOS vision of having MacOS without paying for it to my computing experience ... Honestly, so many things just work on MacOS and just need hours of tweaking for us.. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 08:53 +, Sven Vermeulen wrote: On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I use a separate /usr with LVM on all my systems. My root partition uses RAID1. And I never had the need for an initramfs of any kind. Also, there are some major hurdles to take when it comes to getting an initramfs working with SELinux. Most initramfs implementations I saw are not SELinux aware, so all changes they make to the system either result in failures when they try, or failures when the root-switch occurs. dracut fully supports SELinux (it's used in Fedora which has this SELinux horror on by default). 3) Try to maintain things the way they are as long as possible. I'm all for this one. But if people really want to focus on initramfs, I'd appreciate some documentation help on it. Not only on how to create one, but also why it is necessary, how to manage initramfs'es, the concepts underlying, etc. Short version: use dracut. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 01 Jan 2012 15:21:24 -0500 Olivier Crête tes...@gentoo.org wrote: Honestly, so many things just work on MacOS and just need hours of tweaking for us.. The problem with just works is that when it breaks, it can't be fixed. Not being able to handle /usr on its own filesystem is a perfect example of this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Olivier Crête wrote: On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote: On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crêtetes...@gentoo.org wrote: All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 14:51 -0600, Dale wrote: Olivier Crête wrote: On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote: On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crêtetes...@gentoo.org wrote: All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? This is a discussion about the future... Changing keywords is trivial if we care. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 20:23 +, Ciaran McCreesh wrote: On Sun, 01 Jan 2012 15:21:24 -0500 Olivier Crête tes...@gentoo.org wrote: Honestly, so many things just work on MacOS and just need hours of tweaking for us.. The problem with just works is that when it breaks, it can't be fixed. Not being able to handle /usr on its own filesystem is a perfect example of this. systemd/dracut/etc handles /usr on its own filesystem just fine. What is required is that /usr must be mounted before the pivot_root away from the initramfs. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, Jan 01, 2012 at 02:12:22AM -0500, Olivier Crête wrote: The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and unmaintained upstream shows that even a relatively large Why do you say that OpenRC is unmaintained upstream? OpenRC is actively maintained in Gentoo, with the largest contributors being WilliamH, vapier, idl0r and myself. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-01-01 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-01-01 23h59 UTC. Removals: sec-policy/selinux-xfce42011-12-26 13:07:19 swift Additions: dev-util/visualvm 2011-12-26 14:11:39 fordfrog mail-client/alot2011-12-26 17:01:42 aidecoe sci-geosciences/gshhs 2011-12-27 07:51:06 bicatali dev-python/twisted-pair 2011-12-27 07:52:16 floppym sci-geosciences/gshhs-data 2011-12-27 07:52:45 bicatali dev-ruby/sprockets 2011-12-27 09:04:31 graaff dev-python/diff-match-patch 2011-12-27 13:07:18 aidecoe dev-python/msgpack 2011-12-28 03:26:16 patrick dev-ruby/rack-protection2011-12-28 12:27:41 graaff dev-java/miglayout 2011-12-28 16:24:33 sera dev-ruby/bson 2011-12-28 23:47:54 flameeyes dev-ruby/mongo 2011-12-28 23:56:06 flameeyes dev-ruby/inifile2011-12-29 00:48:37 flameeyes dev-libs/userspace-rcu 2011-12-29 10:34:50 scarabeus net-dns/knot2011-12-29 11:06:56 scarabeus dev-ruby/rack-ssl 2011-12-29 16:39:45 graaff sci-astronomy/idlastro 2011-12-29 23:07:22 bicatali dev-python/envoy2011-12-30 06:50:30 patrick dev-ruby/execjs 2011-12-30 12:39:32 graaff sys-fs/ext4magic2011-12-30 12:40:33 ssuominen dev-ruby/uglifier 2011-12-30 12:46:30 graaff dev-ruby/coffee-script-source 2011-12-30 13:18:46 graaff dev-ruby/coffee-script 2011-12-30 13:21:15 graaff dev-ruby/coffee-rails 2011-12-30 13:31:44 graaff net-libs/librouteros2011-12-30 20:16:49 maksbotan app-text/kpaste 2011-12-31 04:57:04 floppym games-board/gmchess 2011-12-31 19:39:32 mr_bones_ -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: sec-policy/selinux-xfce4,removed,swift,2011-12-26 13:07:19 Added Packages: dev-util/visualvm,added,fordfrog,2011-12-26 14:11:39 mail-client/alot,added,aidecoe,2011-12-26 17:01:42 sci-geosciences/gshhs,added,bicatali,2011-12-27 07:51:06 dev-python/twisted-pair,added,floppym,2011-12-27 07:52:16 sci-geosciences/gshhs-data,added,bicatali,2011-12-27 07:52:45 dev-ruby/sprockets,added,graaff,2011-12-27 09:04:31 dev-python/diff-match-patch,added,aidecoe,2011-12-27 13:07:18 dev-python/msgpack,added,patrick,2011-12-28 03:26:16 dev-ruby/rack-protection,added,graaff,2011-12-28 12:27:41 dev-java/miglayout,added,sera,2011-12-28 16:24:33 dev-ruby/bson,added,flameeyes,2011-12-28 23:47:54 dev-ruby/mongo,added,flameeyes,2011-12-28 23:56:06 dev-ruby/inifile,added,flameeyes,2011-12-29 00:48:37 dev-libs/userspace-rcu,added,scarabeus,2011-12-29 10:34:50 net-dns/knot,added,scarabeus,2011-12-29 11:06:56 dev-ruby/rack-ssl,added,graaff,2011-12-29 16:39:45 sci-astronomy/idlastro,added,bicatali,2011-12-29 23:07:22 dev-python/envoy,added,patrick,2011-12-30 06:50:30 dev-ruby/execjs,added,graaff,2011-12-30 12:39:32 sys-fs/ext4magic,added,ssuominen,2011-12-30 12:40:33 dev-ruby/uglifier,added,graaff,2011-12-30 12:46:30 dev-ruby/coffee-script-source,added,graaff,2011-12-30 13:18:46 dev-ruby/coffee-script,added,graaff,2011-12-30 13:21:15 dev-ruby/coffee-rails,added,graaff,2011-12-30 13:31:44 net-libs/librouteros,added,maksbotan,2011-12-30 20:16:49 app-text/kpaste,added,floppym,2011-12-31 04:57:04 games-board/gmchess,added,mr_bones_,2011-12-31 19:39:32 Done.
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
That's what I had in mind, and in fact have already been thinking about
trying, here.
Which is why I don't really like the idea of packages placing symlinks,
since then it'd likely be the symlink copied last, overwriting the actual
binary with the symlink... pointing at itself due to the symlinked dirs!
Which is why I suggested a portage feature that would detect such
collisions and die before installing them, potentially overwriting the
binary with a symlink to itself!
--
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] rfc: locations of binaries and separate /usr
On Sun, Jan 1, 2012 at 8:59 AM, William Hubbs willi...@gentoo.org wrote: Udev, kmod (which is a replacement for module-init-tools which will be needed by =udev-176), systemd, and soon others, are advocating a major change to the locations where binaries and libraries are stored on linux systems. Could you please point me to the discussions where udev, kmod and soon others are advocating /usr/bin and /bin unification? -- Duy
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On 01/01/2012 09:39 PM, Duncan wrote:
Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
That's what I had in mind, and in fact have already been thinking about
trying, here.
Which is why I don't really like the idea of packages placing symlinks,
since then it'd likely be the symlink copied last, overwriting the actual
binary with the symlink... pointing at itself due to the symlinked dirs!
Which is why I suggested a portage feature that would detect such
collisions and die before installing them, potentially overwriting the
binary with a symlink to itself!
It should not be a problem because merge of symlinks is automatically
delayed in cases when the symlink target doesn't exist yet. There's a
loop where it merges as many regular files as it can, and if there are
any symlinks that can't be resolved then it merges them after all the
regular files have been merged.
--
Thanks,
Zac
