[gentoo-catalyst] Relative paths in spec files

[gentoo-catalyst] Relative paths in spec files

[Ted Kosan]

I am attempting to switch a number of the absolute paths which are present in
my spec files and in my catalyst configuration file into relative paths.  

For example, I would like to replace an absolute path like this:

envscript="/home/tkosan/checkouts/jdos/jdos/catalyst_config_files/catalyst-env.sh"


with a relative path like this:

envscript="../catalyst_config_files/catalyst-env.sh"


I have been studying the python code for catalyst_v2.0_rc50.  The file_locate
function near line 506 in catalyst_support.py appears to support relative
paths, but the following code that calls this function near line 157 in
generic_stage_target.py seems to be disabling path expansion by setting
"expand" to 0:


<code_snip>
# this next line checks to make sure that the specified variables exist on
disk.
#pdb.set_trace()
		file_locate(self.settings,["source_path","snapshot_path","distdir"],expand=0)

# if we are using portage_confdir, check that as well
if self.settings.has_key("portage_confdir"):
			file_locate(self.settings,["portage_confdir"],expand=0)
</code_snip>


Is there a way to enable the use of relative paths in the spec files and in the
catalyst configuration file that perhaps I am not aware of?

Thanks in advance :-)

Ted Kosan
tkosan@dev.java.net
-- 
gentoo-catalyst@gentoo.org mailing list

Re: [gentoo-catalyst] Relative paths in spec files

[Andrew Gaffney]

Ted Kosan wrote:
> Is there a way to enable the use of relative paths in the spec files and in the
> catalyst configuration file that perhaps I am not aware of?

Relative paths don't really work unless you specify somewhere what they are 
relative to (current dir isn't really a good option). For example, relative 
paths work in the apache config, because the config root is specified as 
/usr/lib/apache2/conf (which is a symlink to /etc/apache2).

With catalyst, there are so many paths that could be the "root" 
(/var/tmp/catalyst, /etc/catalyst, some random dir where you store your specs, 
etc.) that it just doesn't work.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
-- 
gentoo-catalyst@gentoo.org mailing list

Re: [gentoo-catalyst] Relative paths in spec files

[Ted Kosan]

Andrew wrote:

> Relative paths don't really work unless you specify somewhere what they are 
> relative to (current dir isn't really a good option). For example, relative 
> paths work in the apache config, because the config root is specified as 
> /usr/lib/apache2/conf (which is a symlink to /etc/apache2).
> 
> With catalyst, there are so many paths that could be the "root" 
> (/var/tmp/catalyst, /etc/catalyst, some random dir where you store your
> specs, 
> etc.) that it just doesn't work.

What I am in the process of doing is putting together a pre-configured
Catalyst-based LiveCD build environment that is newbie-friendly and housed in a
CVS.  When a Catalyst newbie checks this build environment out of the CVS, I
was hoping to have the Catalyst configuration file and the spec files already
pointing to the resources they need to ( which are also present in the checked
out environment ).

The ability to use relative paths in the Catalyst configuration file and the
spec files seems like it would work for this use.

I have experimented with placing "print os.getcwd()" in the catalyst2 script
and it indicates that the current working directory is set to whatever
directory this script is launched from.

This is the behavior I am interested in using because, after checking the
LiveCD build environment out of the CVS, I would like the user to change into a
specific directory which contains short scripts that will allow them to build
various targets.

I am currently experimenting with removing "expand=0" from the calls to the
file_locate function on lines 159 and 162 in generic_stage_target.py to see if
this breaks anything.

Thanks :-)

Ted Kosan
tkosan@dev.java.net

-- 
gentoo-catalyst@gentoo.org mailing list

Re: [gentoo-catalyst] Relative paths in spec files

["Andreas Rückert"]

Hi!

-------- Original-Nachricht --------
Datum: Tue, 8 Aug 2006 23:07:21 -0700 (PDT)
Von: Ted Kosan <tkosan@yahoo.com>
An: gentoo-catalyst@lists.gentoo.org
Betreff: Re: [gentoo-catalyst] Relative paths in spec files

--<snip>--
 
> What I am in the process of doing is putting together a pre-configured
> Catalyst-based LiveCD build environment that is newbie-friendly and housed
> in a
> CVS.

Consider to use trac. Comes with subversion and wiki. Good experiences with it here...
http://trac.edgewall.org/

>  When a Catalyst newbie checks this build environment out of the CVS,
> I
> was hoping to have the Catalyst configuration file and the spec files
> already
> pointing to the resources they need to ( which are also present in the
> checked
> out environment ).
> 
> The ability to use relative paths in the Catalyst configuration file and
> the
> spec files seems like it would work for this use.
> 
> I have experimented with placing "print os.getcwd()" in the catalyst2
> script
> and it indicates that the current working directory is set to whatever
> directory this script is launched from.

What we did here, is writing make files. Such things are handled with m4 here. Also stuff like the
timestamp. So you'd call 
make snapshot livecd_stage1 livecd_stage2 write_cd
here to create a new livecd and burn it.

But a build.xml file and jakarta-ant are also an option.

--<snip>--

Ciao,
Andreas

-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
-- 
gentoo-catalyst@gentoo.org mailing list

Re: [gentoo-catalyst] Relative paths in spec files

[Ted Kosan]

Andreas wrote:

> What we did here, is writing make files. Such things are handled with m4
> here. Also stuff like the
> timestamp. So you'd call 
> make snapshot livecd_stage1 livecd_stage2 write_cd
> here to create a new livecd and burn it.

I thought about this approach but then I decided to pursue the route of using
relative paths instead.  The reason for this is that my goal with the CVS
checkout strategy is primarily educational.

Instead of shielding a Catalyst newbie from the details of how to configure
Catalyst and use it, what I am interested in doing is helping to explain it.

As part of this approach, what I would like to do is to reduce the amount of
error-prone typing a Catalyst newbie has to do in order to achieve their
initial error-free target builds.

Here is the directory structure that I am putting together in the CVS:

CVS                    fsscript_file        motd_file     spec_files
catalyst_config_files  kernel_config_files  portage_conf  store_dir
livecd_overlay         root_overlay

My goal is to have all of the configuration files needed to build targets
contained within this directory structure.  The ability for Catalyst to work
with relative paths would significantly reduce the need for the user to edit
the various paths that are present in the Catalyst config file and the spec
files before they can attempt their initial target builds.

Thank you, though, for your suggestion of using make or ant to help with
Catalyst builds.  Now that I know that others are using this approach I think I
will experiment with it a bit to see how well it works :-)

Ted Kosan
tkosan@dev.java.net



-- 
gentoo-catalyst@gentoo.org mailing list

[gentoo-catalyst] Re: Relative paths in spec files

[Charles Duffy]

Andrew Gaffney wrote:
> With catalyst, there are so many paths that could be the "root" 
> (/var/tmp/catalyst, /etc/catalyst, some random dir where you store your 
> specs, etc.) that it just doesn't work.

I'm not sure that's a problem in everyone's environment.

In my case, I want to be able to check my complete set of configuration 
for catalyst (spec files, overlays, linuxrc replacements, etc etc) into 
subversion and have it Just Work regardless of exactly where the user 
checks it out to. The key here is that because things are stored in 
subversion in a specific tree layout, I know with certainty what the 
relative paths look like on-disk, but I know nothing at all about the 
absolute path.

Now, I can do this by hand by checking .spec.in files into svn and 
preprocessing them, but that's ugly as sin; I'd much prefer to make 
catalyst/modules/parse_spec.py support environment variable substitution 
or somesuch, at least if `yall (agaffney, chris) would accept such a patch.

Would ${VARNAME} be acceptable to substitute in environment variables 
(with ${PWD} being special), or would this stomp on some other 
legitimate syntax?

-- 
gentoo-catalyst@gentoo.org mailing list