Summary: | baselayout virtual needed for macos | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Lina Pezzella (RETIRED) <j4rg0n> |
Component: | [OLD] Core system | Assignee: | osx porters <osx> |
Status: | RESOLVED WONTFIX | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 57448, 57596, 58892, 59230, 61638, 63050, 65295, 73170, 73217, 79368, 79911, 80032, 87499 | ||
Attachments: |
darwin-initd.eclass
Hacked to compile on darwin |
Description
Lina Pezzella (RETIRED)
2004-07-23 12:25:56 UTC
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. |