baselayout contains runscript.sh, which is needed for init scripts. Emerging baselayout in its current form would break MacOSX. 14:40 <@j4rg0n> also, what about packages like baselayout? 14:40 <@j4rg0n> that happens to contain runscript, which is needed for most ebuilds with an init script 14:40 <@pvdabeel> we need a virtual vor that: 14:40 <@j4rg0n> but it also contains things we don't want to overwrite 14:40 <@j4rg0n> like passwd 14:40 <@pvdabeel> virtual/Baselayout -> sys-apps/baselayout in linux 14:40 <@pvdabeel> virtual/Baselayout -> sys-apps/baselayout-macos for macos 14:41 <@pvdabeel> indeed 14:41 <@j4rg0n> okay, so the baselayout-macos version would take out the stuff we don't wanna overwrite 14:41 <@pvdabeel> indeed 14:41 <@pvdabeel> it also takes care of installing in a directory like /gentoo 14:41 <@j4rg0n> are you the appropriate person to make such magic happen? 14:41 <@pvdabeel> or /opt/local or something
Methinks Gentoo/*BSD could benefit from this too...
I've started work on this, pvdabeel, can you comment further on what you mean by having baselayout install into a seperate directory? I thought that was part of pathspec? I realize baselayout does setup the directory structure, but I'm not sure how that works with pathspec. Right now I've got an ebuild that will install the environment related stuff, I'm working on making sure that the init scripts work as well. I'll post an ebuild when it's finished.
Does anything non-profile actually have an explicit baselayout dep? If not, no need for a virtual.
Just a few examples from a quick grep: /usr/portage/app-sci/foldingathome/foldingathome-4.0.0-r1.ebuild:DEPEND=">=sys-apps/baselayout-1.8.0 /usr/portage/app-sci/foldingathome/foldingathome-4.0.0-r2.ebuild:DEPEND=">=sys-apps/baselayout-1.8.0 /usr/portage/app-sci/foldingathome/foldingathome-4.0.0.ebuild:DEPEND=">=sys-apps/baselayout-1.8.0 /usr/portage/app-sci/gimps/gimps-23.5.ebuild:DEPEND=">=sys-apps/baselayout-1.8.0 /usr/portage/app-sci/gimps/gimps-23.9.ebuild:DEPEND=">=sys-apps/baselayout-1.8.0 /usr/portage/app-sci/setiathome/setiathome-3.03-r1.ebuild:DEPEND=">=sys-apps/baselayout-1.8.0" /usr/portage/app-sci/setiathome/setiathome-3.08-r3.ebuild:DEPEND=">=sys-apps/baselayout-1.8.0"
Hrm, all of those are binary only, no?
Good question. We need baselayout anyways for runscript.sh though...
Created attachment 43657 [details] darwin-initd.eclass I played with Gentoo init.d few hours to get some Japanese input methods work but finally I noticed that we need /sbin/runscript (and /sbin/start-stop-daemon, both are in baselayout package) to execute Gentoo init.d script :( I attach a sample eclass to convert Gentoo init.d into StartupItems. I couldn't test more as we don't have baselayout package available for Mac OS X. Is there anybody working on this issue?
usata: just last night i was hacking on the bsd scripts that spb did. I managed to get most of it working, but with a few caveats: requires either gawk or a complete install of awk , as apple does not ship all the awk headers with os x(not a 'supported' api' ) i havent been able to get depcache working yet some functions in /lib/rcscripts/awk/functions.awk might need to be re-written But the basics seem to be working, rc-{status,update} , start-stop-daemon, etc. I'll look at it more tonight....
Thanks for your speedy response. Do we really need depcache for Mac OS X? We already have SystemStarter based service dependency check, so if converting Gentoo init.d script to Mac OS X StartupItems has no problem I don't think we need it. /etc/init.d/somedaemon start might be broken, but if SystemStarter SomeDaemon start works I think it's okay. (Because most of Gentoo /etc/init.d scripts are useless for Mac OS X, and we typically add several daemons to Mac OS X services) Any comments on this?
I guess depcache isn't a necessity, I was looking for a way to do it without having to modify any ebuilds, and also having a scalable solution that could work for {o}darwin as well. I've heard/read conflicting reports as to the future of SystemStarter, some have said it is deprecated and will go away in the near future... /etc/mach_init_per_user.d is now the 'preferred' way to deal with daemons AFAICT.
Using /etc/mach_init.d is much easier to convert, but how can we express complex syntax like "need" and "use"?
well, I'm thinking that the ideal solution is to just have the normal mach startup kickstart the gentoo init.d scripts, as opposed to converting all init.d scripts to mach_init*, but that brings us back to porting depcache, etc. i could be making this more complex than it really is though...
Meh. Not using the standard Gentoo init system is gonna cause a hell of a mess...
I vote for solution #12. So do we take a vote or something? This has been sitting here a while...
looks like having the gentoo init system kickstarted by the mach one is what we're after. any implementation on this?
Created attachment 49123 [details] Hacked to compile on darwin
In addition to an init system, baselayout should provide a libtool wrapper directory as follows (in pseudocode): mkdir some-dir/libtool-wrap ln -sf /usr/bin/glibtool some-dir/libtool-wrap/libtool export PATH=/usr/local/libtool-wrap:$PATH >> profile_bashrc This will force packages that use their own version of libtool to use ours instead. For instance, this fixes the jpeg and ttmkfdir bugs, which have been patched quite hackishly in the meantime.
Don't think baselayout would be the right place for that. Maybe a darwin-centric libtool ebuild? Or maybe somehow use the libtool eclass?
If the libtool wrapper actually installed some sort of binary I'd say to go for a separate ebuild, but it's just a symlink and a directory. So if you really think of it, it's more of a layout issue. Additionally, providing this in baselayout will allow us to require baselayout as a part of the system profile, meaning that we won't have to depend on the libtool ebuild in every package that needs the fix (quite a few). Sure, we could depend on the libtool ebuild as a part of system profile too, but it just needlessly complicates things imho.
I've added a very basic baselayout-darwin and coreutils-darwin that fix enough stuff to get env.d and profile stuff working correctly. Next up we'll get init working on darwin. (perhaps we can look into backporting launchd if it isn't already being done?) As for the libtool fix, we definitely could include it in baselayout, has the above solution been tested? We could easily just include that fix in the layout and add the profile stuff to the profile.gentoo.
Awesome work, Joe. I'm fairly certain that we no longer need a libtool wrapper since we now have profile.bashrc. Can anyone confirm this?
We (bsd) shouldn't be interested anymore in this :) The virtual is there and the rest is osx things I think.
Is this bug still relevant? Can it be closed/resolved? Is it worth putting some time in before we get some better solution?
close this piece of pain.
