Menu
▾
▴
ark-dev
|
From: Will P. <pa...@dc...> - 2005-11-07 20:59:54
|
Hi, Jim (and others) -- Arusha land is pretty quiet, but still here... On your various remarks: > 1.) A sidai suggestion: sidai/package/rsync.xml has a phrase in the > <patch> section that names a bunch of rsync versions. I think the > sense of the test should be reversed, so it tests *for* [ > "$PKG_VERSION" = "2.5.5" ] and defaults to : ok # no worries, mate. > (The "doesn't need a patch" list is already out of date, 2.6.6 is out > and the build fails because of this...) *Yes*. There are many instances of equally egregious code. Reason: the shortest path to success is to add '-o <new-version>' and move on. But, this being "collaborative sysadmin", I guess I'll need to do better :-) > 2.) Mostly a statement: the 'how do I migrate from the "try-ark" mode > to a real site' instructions are .... lacking. I got a bit frustrated > trying to discover in which dark corner the magic config file that was > causing certain behavior lived... turned out I had a mixture of old > and new happening, and didn't know that, because of the level of magic > involved. At that early phase of maturity, this needs to be smoother. > (I know -- send patches... :) Urgh. I _do_ tend to test that stuff before releases (which are now about a year apart -- CVS updates happen, of course...), but of course I never see it with newbie eyes. All advice welcome... > 3.) Newbie Q: what happens if a machine is down when a deploy/reveal > command is issued? Is there anything akin to "self-healing state > management" in here? Er, not really. There may be some command-line gunk (--down-hosts=?) to advise the tool to steer clear; I'd have to look it up. You can also change a host <status> to "pending", which means it will get put into tables and things (i.e. its a "player") but won't get ssh'd to. I often do this if I know a machine's going to be down for a few days. The _right_ solution is something like a client cron job that does 'ark package reveal ALL' every 15 mins. This would need some slight extra mechanism (which I've never needed) for someone to say "this one is good to go", after which the cron job would get it. The machinery exists... ark package good-to-go synopsys-vcs--2005.06 ... which does little more than 'touch' some sentinel; then change the deploy method a bit to look for the sentinel. > 4.) Anyone done any windows integration? Thoughts in that direction? Um... sorry. > 5.) Are there any utilities/commands to report on the ark-state info? No; there should be. Got an idea for one? -- maybe we could write it. > 6.) A sidai question: I built a version of gcc to go into /our; used > the sidai template with just a couple of tiny tweaks. It got > installed/deployed in a somewhat unexpected manner -- in the deploy > tree I have a whole tree of subdirectories, and (most of) the leaves > are symlinks into the install tree. A couple of things are directly > stored in the deploy tree. All the other apps I've done so far have > the top of the deploy tree just symlinked to the top of the respective > install tree. Is this expected, and if so -- what is the logic behind > doing it this way; and what directive triggered the different install? The idea was: for a few bits of a GCC build (libgcc.so for example), you really don't want to be making NFS trips to get it. So each (per-client) deployment has a copy of that. On the other hand, for swathes of a GCC distribution, one shared copy is fine. So symlinks to those bits. The guilty party is ($ARK/sidai/package/gcc.xml): <deployment-spec><table><entry name="*"> @TYPE@=manifest ^lib/lib.*\.so copy * * 755 . link </entry></table></deployment-spec> If you just wanted to copy blindly, you'd change (override) that with <deployment-spec><table><entry name="*"> @TYPE@=copy </entry></table></deployment-spec> for example. Will |
|
From: Will P. <pa...@dc...> - 2005-11-11 10:51:56
|
Jim Rowan writes:
> RCS file: /cvsroot/ark/sidai/package/GNU.xml,v
> retrieving revision 1.36
> diff -u -r1.36 GNU.xml
> --- GNU.xml 11 Apr 2005 11:29:09 -0000 1.36
> +++ GNU.xml 9 Nov 2005 23:39:59 -0000
> @@ -121,7 +121,7 @@
> eval "$pre_config_eval"
> fi
> -CONFIG_SHELL="$CONFIG_SHELL" \
> +CONFIGURE="$CONFIG_SHELL" \
> CC="$cc" \
> CXX="$cxx" \
> CPPFLAGS="$cppflags" \
Hmm... I don't buy this. It simply says "Don't set CONFIG_SHELL"
(which is probably not right for all GNU-built programs, which is what
that prototype is for), and instead sets the CONFIGURE environment
variable... which is never used in a configure script. (I checked the
Python one and one or two others.)
You will note that the <host> prototypes
sidai/host/{linux,solaris}.xml have settings for <CONFIG-SHELL>, to
either /bin/bash or /bin/ksh, respectively.
Did you try setting <CONFIG-SHELL> for your relevant host (the one
doing the building), either with the sidai prototype, or one of your
own (or just directly in your <host>.xml)?
If setting CONFIG-SHELL correctly doesn't work, then we have a problem
:-)
Will
|
|
From: Jim R. <jm...@qu...> - 2005-11-11 18:35:09
|
Will Partain wrote:
>Jim Rowan writes:
>
>
>
>>RCS file: /cvsroot/ark/sidai/package/GNU.xml,v
>>retrieving revision 1.36
>>diff -u -r1.36 GNU.xml
>>--- GNU.xml 11 Apr 2005 11:29:09 -0000 1.36
>>+++ GNU.xml 9 Nov 2005 23:39:59 -0000
>>@@ -121,7 +121,7 @@
>> eval "$pre_config_eval"
>> fi
>> -CONFIG_SHELL="$CONFIG_SHELL" \
>>+CONFIGURE="$CONFIG_SHELL" \
>> CC="$cc" \
>> CXX="$cxx" \
>> CPPFLAGS="$cppflags" \
>>
>>
>
>Hmm... I don't buy this. It simply says "Don't set CONFIG_SHELL"
>(which is probably not right for all GNU-built programs, which is what
>that prototype is for), and instead sets the CONFIGURE environment
>variable... which is never used in a configure script. (I checked the
>Python one and one or two others.)
>
>You will note that the <host> prototypes
>sidai/host/{linux,solaris}.xml have settings for <CONFIG-SHELL>, to
>either /bin/bash or /bin/ksh, respectively.
>
>Did you try setting <CONFIG-SHELL> for your relevant host (the one
>doing the building), either with the sidai prototype, or one of your
>own (or just directly in your <host>.xml)?
>
>If setting CONFIG-SHELL correctly doesn't work, then we have a problem
>:-)
>
>
I know *I* have a problem. :)
Yes, I set CONFIG_SHELL. No, it didn't work. (I just went back and
don't see where it was set -- so I reran the whole test again. It is
current set in arik/sparc_solaris.xml, a template for cactus-aus where
tthe build is happening.)
Here is some relevant output:
cactus-aus$ ark package configure --hosts=. --verbose python--2.4.2
> configure on python--2.4.2 ( not done before )
[FROM: param PKG_PROTO_HOST - sidai:package/python [M 1.25 +
2005.11.09 15:11.07],
param dep_iflags - sidai:package/python [M 1.25 +
2005.11.09 15:11.07],
param dep_lflags - sidai:package/python [M 1.25 +
2005.11.09 15:11.07],
param pre_config_eval - sidai:package/python [M 1.25 +
2005.11.09 15:11.07],
param extra_configure_args - arik:package/GNU [? + 2005.11.02
11:34.15],
code - sidai:package/GNU [M 1.36 + 2005.11.11 11:22.40] ]
>> host: cactus-aus [for hosts: sparc-solaris9]
PKG_PROTO_HOST=sparc-solaris9
dep_iflags=-I/our/.-ark-deploy/python--2.4.2/include
dep_lflags=-L/our/.-ark-deploy/python--2.4.2/lib
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
pre_config_eval=/bin/rm -f Iflags Lflags; echo "$dep_iflags" > Iflags;
echo "$dep_lflags" > Lflags
extra_configure_args=--disable-nls
FIND=/usr/bin/find
XARGS=/usr/bin/xargs
cc=/our/bin/gcc
cxx=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
ccboot=/pkg/gnu_compilers/gcc-3.2.3/bin/gcc
cxxboot=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
cppflags= -I/our/.-ark-deploy/python--2.4.2/include
cflags=-O2 -fstrict-aliasing -I/our/.-ark-deploy/python--2.4.2/include
cxxflags=-O2 -I/our/.-ark-deploy/python--2.4.2/include
ldflags= -L/our/.-ark-deploy/python--2.4.2/lib
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
cppflagsboot= -I/our/.-ark-deploy/python--2.4.2/include
cflagsboot=-O2 -fstrict-aliasing -I/our/.-ark-deploy/python--2.4.2/include
cxxflagsboot=-O2 -I/our/.-ark-deploy/python--2.4.2/include
ldflagsboot= -L/our/.-ark-deploy/python--2.4.2/lib
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
in_dir=.
CONFIG_SHELL=/bin/ksh
CONFIGURE=./configure
configure_args=
prefix=/our/.-ark-deploy/python--2.4.2
+ cd
/prj/qct/sysadmin/aus-it/arik/ark-builds/python--2.4.2/sparc-solaris9/.
+ /usr/bin/xargs+ /usr/bin/find . ( -name config*.cache -o -name
autom4te.cache -o -name config.log -o -name config.status -o -name
conftest.c ) -print
/bin/rm -rf
+ [ x != x ]
+ sidaiPickProgram /our/bin/gcc /pkg/gnu_compilers/gcc-3.2.3/bin/gcc
+ echo /our/bin/gcc
+ sed -e s/ .*//
p_w1=/our/bin/gcc
+ [ -x /our/bin/gcc ]
+ echo /our/bin/gcc
+ return
cc=/our/bin/gcc
+ [ x/our/bin/gcc = x/pkg/gnu_compilers/gcc-3.2.3/bin/gcc ]
+ sidaiPickProgram /pkg/gnu_compilers/gcc-3.2.3/bin/c++
/pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ + sedecho /pkg/gnu_compilers/gcc-3.2.3/bin/c++
-e s/ .*//
p_w1=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ [ -x /pkg/gnu_compilers/gcc-3.2.3/bin/c++ ]
+ echo /pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ return
cxx=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ [ x/pkg/gnu_compilers/gcc-3.2.3/bin/c++ =
x/pkg/gnu_compilers/gcc-3.2.3/bin/c++ ]
cppflags= -I/our/.-ark-deploy/python--2.4.2/include
cxxflags=-O2 -I/our/.-ark-deploy/python--2.4.2/include
ldflags= -L/our/.-ark-deploy/python--2.4.2/lib
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
+ [ x/bin/rm -f Iflags Lflags; echo "$dep_iflags" > Iflags; echo
"$dep_lflags" > Lflags != x ]
+ eval /bin/rm -f Iflags Lflags; echo "$dep_iflags" > Iflags; echo
"$dep_lflags" > Lflags
+ /bin/rm -f Iflags Lflags
+ echo -I/our/.-ark-deploy/python--2.4.2/include
+ echo -L/our/.-ark-deploy/python--2.4.2/lib
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
+ ./configure --prefix=/our/.-ark-deploy/python--2.4.2 --disable-nls
LDFLAGS= -L/our/.-ark-deploy/python--2.4.2/lib
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib CXXFLAGS=-O2
-I/our/.-ark-deploy/python--2.4.2/include CFLAGS=-O2 -fstrict-aliasing
-I/our/.-ark-deploy/python--2.4.2/include CPPFLAGS=
-I/our/.-ark-deploy/python--2.4.2/include
CXX=/pkg/gnu_compilers/gcc-3.2.3/bin/c++ CC=/our/bin/gcc
CONFIG_SHELL=/bin/ksh
checking MACHDEP... sunos5
checking EXTRAPLATDIR...
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for c++... /pkg/gnu_compilers/gcc-3.2.3/bin/c++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for gcc... /our/bin/gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /our/bin/gcc accepts -g... yes
checking for /our/bin/gcc option to accept ANSI C... none needed
....
checking for broken nice()... no
checking for broken poll()... no
checking for struct tm.tm_zone... (cached) no
checking for tzname... (cached) yes
checking for working tzset()... yes
checking for tv_nsec in struct stat... yes
checking whether mvwdelch is an expression... yes
checking whether WINDOW has _flags... yes
checking for /dev/ptmx... ./configure: test: argument expected
cactus-aus$
The test for /dev/ptmx involves "test -e". QED.
I can tell that CONFIG_SHELL ended up being set in the environment in
which configure was run; the config.log created shows
SHELL='/bin/ksh'
Unfortunately, it doesn't get far enough to create config.status or
config.log, which would be nicer to see what is really going on. I am
not enough of a configure/autoconf wizard to understand in detail how it
works ... but my understanding is that if SHELL gets set then it will
have exec'd SHELL to run itself. I don't see why it fails.
Somehow this failure is being *introduced* by the way ark is invoking
configure -- I don't get it -- but:
I run this:
/bin/sh (my normal shell is zsh)
SHELL=/bin/sh
export SHELL
<check that no CONFIG_SHELL variable is set in my env...>
./configure
And it succeeds. The resulting config.status tells me that it chose
to run it under /bin/bash.
cactus-aus$ head config.status
#! /bin/bash
# Generated by configure.
# Run this file to recreate the current configuration.
# Compiler output produced by configure, useful for debugging
# configure, is in config.log if it exists.
debug=false
ac_cs_recheck=false
ac_cs_silent=false
SHELL=${CONFIG_SHELL-/bin/bash}
|
|
From: Will P. <pa...@dc...> - 2005-11-11 19:24:19
|
Jim Rowan wrote: > + ./configure --prefix=/our/.-ark-deploy/python--2.4.2 --disable-nls > LDFLAGS= -L/our/.-ark-deploy/python--2.4.2/lib > -Wl,-R/our/.-ark-deploy/python--2.4.2/lib CXXFLAGS=-O2 > -I/our/.-ark-deploy/python--2.4.2/include CFLAGS=-O2 -fstrict-aliasing > -I/our/.-ark-deploy/python--2.4.2/include CPPFLAGS= > -I/our/.-ark-deploy/python--2.4.2/include > CXX=/pkg/gnu_compilers/gcc-3.2.3/bin/c++ CC=/our/bin/gcc > CONFIG_SHELL=/bin/ksh Hmmm... Well, at least we know it got set. Doing a little test on this sol10 box: partain@slimy% ksh $ test -e ~/foo $ type test test is a shell builtin $ test -e ksh: test: argument expected $ test -e /dev/ptmx $ echo $? 0 $ In summary: it makes no sense at all :-( Unless you have some other program called 'test' in your PATH and it misbehaves in just the right way... I doubt it. What if you change your <CONFIG-SHELL> setting for solaris to /bin/bash? I mean, if you've *got* a /bin/bash, I would expect GNU stuff to be very bash-friendly. An unsatisfactory answer... I hate things like this :-) Will |
|
From: Jim R. <jm...@qu...> - 2005-11-11 22:06:28
|
Will Partain wrote: > > >Hmmm... Well, at least we know it got set. Doing a little test on >this sol10 box: > > partain@slimy% ksh > $ test -e ~/foo > $ type test > test is a shell builtin > $ test -e > ksh: test: argument expected > $ test -e /dev/ptmx > $ echo $? > 0 > $ > > I think you're missing the point; I get the same thing with ksh, when testing in this manner. It's sh that doesn't work. And configure, when run from the command line, even compensates for it (by switching to bash). It just doesn't compensate when ark invokes it. THAT's the wierdest part. >In summary: it makes no sense at all :-( Unless you have some other >program called 'test' in your PATH and it misbehaves in just the right >way... I doubt it. > > Nope. In any case, test is built in to sh as well. >What if you change your <CONFIG-SHELL> setting for solaris to /bin/bash? >I mean, if you've *got* a /bin/bash, I would expect GNU stuff to be >very bash-friendly. > >An unsatisfactory answer... I hate things like this :-) > > I'll try it -- but it won't work. .... nope. Exactly the same, except that the debug output said 'CONFIG_SHELL=/bin/bash'. The patch/whack that I had posted (changing CONFIG_SHELL) *did* work -- but I can't fully explain why (ultimately, in not setting CONFIG_SHELL). Here's another thing that did work: <CONFIG-SHELL></CONFIG-SHELL> this results in the --verbose output showing: CONFIG_SHELL= (as one would expect...) and lets configure choose to use bash, sucessfully. And finally, I figured out I should check this outside of ark. export CONFIG_SHELL=/bin/bash ./configure FAILS! This is an autoconf/python configure issue... it doesn't work like it should. :( |
|
From: Will P. <pa...@dc...> - 2005-11-14 15:40:25
|
Jim Rowan writes: > I think you're missing the point; ... No, just floundering helplessly as usual :-) > And finally, I figured out I should check this outside of ark. > export CONFIG_SHELL=/bin/bash > ./configure > > FAILS! This is an autoconf/python configure issue... it doesn't work > like it should. :( Well figured-out. This would suggest that the Sidai-ish way to encode your knowledge is not to set <CONFIG-SHELL> for a host (because it's not a platform-ish thing); rather, in $ARK/sidai/package/python.xml [assuming you're using that as one of your prototypes], record... <configure> <!-- setting config_shell breaks things as at version 2.x.y --> <param name="CONFIG_SHELL"></param> </configure> I guess I'll add that in, unless someone yells. Will |
|
From: Jim R. <jm...@qu...> - 2005-11-14 15:48:07
|
Will Partain wrote: > Well figured-out. This would suggest that the Sidai-ish way to encode > your knowledge is not to set <CONFIG-SHELL> for a host (because it's > not a platform-ish thing); rather, in $ARK/sidai/package/python.xml > [assuming you're using that as one of your prototypes], record... > > <configure> > <!-- setting config_shell breaks things as at version 2.x.y --> > <param name="CONFIG_SHELL"></param> > </configure> > > I guess I'll add that in, unless someone yells. > > > Yes, I agree it should go in there. At this point, I've only confirmed that it needs this on Solaris. (But I don't see how this is likely to hurt elsewhere; it's probably also broken anywhere that actually needs to set CONFIG_SHELL. And if it you don't need to set it, unsetting it won't hurt!) +1 Jim |
|
From: Will P. <pa...@dc...> - 2005-12-02 21:56:25
|
Responding to Jim Rowan... sorry to be so slow.
> I'd love to see the -R stuff go away as well. It is a major detractor.
>
> However, your proposal causes the behavior of ark installed programs
> to be dependant on the configuration of the machine (OS) itself --
[Recap: "my" [vague] proposal was: lose the -R stuff, have some extra
ARK gunk to "manage" the ld.config game (where to find .so files).]
Jim, I agree with your misgivings. After all, something must've
pushed me into this -R thing in the first place :-)
I wonder if some sort of hybrid scheme would make sense? I observe
that not all .so files are created equal...
* things like libgcc_s.so -- every program needs it; carefully managed
by the GCC lads... Why not just put this in your ld.config...
/our/.-ark-deploy/gcc--4.0.2/lib
/our/.-ark-deploy/gcc--3.4.3/lib
/our/.-ark-deploy/gcc--2.95.3/lib
... and declare victory? If your program picks up the version from
a different version than what you might've expected, it will almost
certainly be OK.
* things like libz.so -- very stable interfaces; likely only upgraded
for security reasons; ubiquitous use; versioning done responsibly.
Again, having these picked up from a well-controlled ld.config will
probably be OK.
* things like the Berkeley DB libraries -- you do _not_, on pain of
death, want a program picking up a version other than the one you
explicitly intended! -- a horrible horrible death will certainly
follow. -R all the way.
Of course, judgement calls are being made in all of that. So (if you
decided to try to distinguish between those cases), it would a
delicate bit of ARK scripting to keep it all together.
Meanwhile, I wildly support that you should be able to do the kinds of
things you're trying to do ("you don't need anything but a raw box").
(Let me know if I've forgotten something, e.g. from earlier in the
thread.)
Will
|
|
From: Jim R. <jm...@qu...> - 2005-12-02 22:31:39
|
Will Partain wrote:
>Jim, I agree with your misgivings. After all, something must've
>pushed me into this -R thing in the first place :-)
>
>I wonder if some sort of hybrid scheme would make sense? I observe
>that not all .so files are created equal...
>
>
In some cases it will make sense - yes.
>* things like libgcc_s.so -- every program needs it; carefully managed
> by the GCC lads... Why not just put this in your ld.config...
>
> /our/.-ark-deploy/gcc--4.0.2/lib
> /our/.-ark-deploy/gcc--3.4.3/lib
> /our/.-ark-deploy/gcc--2.95.3/lib
>
> ... and declare victory? If your program picks up the version from
> a different version than what you might've expected, it will almost
> certainly be OK.
>
>
You're probably right about the resilience to version mismatches
aspect. And in the context of within a managed "cluster", doing
something like this isn't particularly hard or evil. Reasonable choice
if it saves some headaches.
>* things like libz.so -- very stable interfaces; likely only upgraded
> for security reasons; ubiquitous use; versioning done responsibly.
> Again, having these picked up from a well-controlled ld.config will
> probably be OK.
>
>* things like the Berkeley DB libraries -- you do _not_, on pain of
> death, want a program picking up a version other than the one you
> explicitly intended! -- a horrible horrible death will certainly
> follow. -R all the way.
>
>
I think these three "classes" are probably reasonably representative of
all the use cases, and it is clear that there is some variation in "how
much it matters".
>Of course, judgement calls are being made in all of that. So (if you
>decided to try to distinguish between those cases), it would a
>delicate bit of ARK scripting to keep it all together.
>
>Meanwhile, I wildly support that you should be able to do the kinds of
>things you're trying to do ("you don't need anything but a raw box").
>
>
This one flies right in the face of the libgcc approach above. In order
to get to this level of sophistication/portability, you have to solve
whatever issues there are completely and "correctly", since you can't
manipulate ld.config. Somewhat unfortunate, but a fact of life. The
ways to solve it that I see are:
1.) -R at build time, specifying all of the libs, and paths to
version-specific deploy dirs -- the way it is done now.
2.) A wrapper that sets LD_LIBRARY_PATH on a per-app basis, with the
info that would have been in "-R" above.
3.) Install apps into some shared dir, abandoning the current
version-specific deploy dirs as the $prefix. Implies giving up full
control of the ability to robustly deploy multiple versions of an app
or lib. If that "shared dir" isn't already on ld.config's path, still
requires some amount of solution ala 1 or 2 above, but the level of
effort will be seriously lowered -- since there's only one path to
push. If that dir is /usr/local; it's likely already solved.
>(Let me know if I've forgotten something, e.g. from earlier in the
>thread.)
>
>
I've been puzzling on this for some time, and I think that the current
approach, while it's a pain in the !@#, is the best one.
I've nailed down my current biggest headache; it's that my current
version of libstdc++ that I have built doesn't have a -R path to libgcc
built in. Now I just have to figure out how to fix it.
Jim
|
|
From: Daniel H. <ha...@li...> - 2005-12-03 19:20:22
|
> [Recap: "my" [vague] proposal was: lose the -R stuff, have some extra
> ARK gunk to "manage" the ld.config game (where to find .so files).]
Not paying attention to any of the sidai stuff (where the
constraints are very different), developers that do *not* understand
the use of RPATH and expect that I either use LD_LIBRARY_PATH or
change the system library path Just Don't Get It and are up there on
the "#!@% me off" list.
The point of -R is for when you're building objects into non
standard locations, which if I remember correctly, sounds like what
you do. Your specific case is mitigated somewhat in that you're
building the whole system, but only somewhat.
The system library path is the system library path for exactly
that; certain unpleasant corners cases are generally vetted by way of
"we promise we won't do this to you" (LD_LIBRARY_PATH has the same
problems where you're taking the promise on yourself).
What happens when my application has a libfoobar.so that includes
a definition of printf? We haven't even started on the fun corner
cases the appear when we introduce dlopen into the picture.
printf is obviously an extreme example, but the point is that I've
actually lived through doing linking the wrong way. ELF brought us
RPATH and taught us to use it for a reason. The previous methods
don't work, and in some cases, people notice.
|
|
From: Will P. <pa...@dc...> - 2006-08-08 12:40:29
|
Hi, Jim et al. -- Taking your questions/comment out of order:
> 3.) Am I out of my mind?
No :-)
> 1.) In this context, are there reasons to keep install and deploy
> distinct? If so, what?
Probably not (i.e. your analysis is sound).
The install/deploy/reveal thing is *not* supposed to be an all-knowing
everyone-should-do-it-this-way thing. It's just one way. The more
common "just stick it in /usr/local" -- make install prefix=/usr/local
-- should also be possible. Or what you want to do.
For the install/deploy/reveal thing, the steps (and what they get you)
go like this:
* You tell the software at build time that it is in the deploy place; i.e.
make install prefix=$deploy_dir [whatever that is]
Because the deploy_dir is traditionally version-specific, you can have
many versions live at once.
* The business of copying over what you've built to the install area
(again version-specifically) is so that you have a single golden copy
per type of machine with which you can do clever things.
* We now deploy the golden cop{y,ies} onto individual machines. If an
individual machine has a big disk (they all do now, but they didn't
when ARK started...), you can deploy by taking a copy. Or you can
deploy by symlinking. Or whatever you like, machine by machine.
Another thing you can customize is what set of versions of the
software each machine sees. So, for example, the Team A machines
might have an old version; but the Team B machines would have all
versions.
* Finally, revealing: This is creating a symlink or something in the
users' PATH so that they can run whatever it is. My experience is
that asking users to meddle with their individual PATHs constantly is
just a recipe for disaster. So, for example, we just say "put
/our/bin near the front of your PATH" and declare victory. Revealing
puts the right links to the right versions in /our/bin. Again, it can
be varied machine by machine (if you're crazy enough to do that).
If you don't want any of that stuff, don't do it that way.
> 2.) Do you have guidance for me in terms of the general approach to
> making them be the same? (i.e, Where do I hack?) Is this going to be a
> big job or a small one? Has anyone done something similar that would be
> useful as a starting point?
I am not aware of someone doing something similar. I hope it would be a
pretty small job.
Assuming you're sucking on the Sidai methods (i.e. in
$ARK/sidai/package/{GNU,ALL}.xml), I'd proceed by...
* cutting out unnecessary methods -- so, for instance, if you want
'reveal-bits' to depend on 'install' rather than 'deploy', just change
the dependency in the 'reveal-bits' method.
* simply change the method shell scripts to do what you want
I'd do them in place (for simplicity). Afterwards, you can move your
changed files out of the way, re-'cvs co' the sidai stuff, then use the
diffs (which I would expect to be modest) to fashion some .xml for your
own team that would then override the sidai stuff and do what you want.
Hope this helps,
Will
|
Thanks for helping keep SourceForge clean.
X