Subject: Re: a few PLIST related questions
To: None <mcmahill@MTL.MIT.EDU>
From: Alistair Crooks <>
List: tech-pkg
Date: 08/14/1998 01:26:29
> So I'm now really close to finishing up this (now several month long)
> packaging effort for scilab-2.4.  I have created a 6330 entry PLIST for
> this beast and have a couple of questions.  

Excellent - thanks for doing this.
> 1)  Several subdirectories are created.  Should those be listed the same
>     way as files or only at the end as
>     @dirrm subdirname

Just the @dirrm subdirname, in the correct order so that parent
directories are listed after child subdirectories e.g.

@dirrm parent/child
@dirrm parent

> 2)  There has been a lot of talk about checksums lately.  I don't
>     completely understand where that comes in so I'll ask this one.
>     The "normal" install procedure for the program (ie not in our
>     package environment) is
>     make all
>     make tarbindist
>     cd final_destination_directory
>     tar -zxvf name_of_tarbindist_file_just_created
>     make
>     The final 'make' sees that you have extracted a binary distribution of
>     the program and it goes in to a couple of scripts and hard codes the
>     path names (using sed).
>     Anyway, my question is then, is this a problem?  I can easily add an
>     install target that does this, but the exact contents of a couple of
>     the installed files will vary depending on ${PREFIX}.  Will this be
>     a problem if this is made into a binary package?  Do I need to do
>     something extra to make it go correctly?

The md5 checksums are done as part of the "fake-pkg" target, which is
performed after the pre-install, do-install, and post-install stages,
when you see the "Registering installation for ${PKGNAME}" message. So
if all the tar steps you mention above are done as part of one of those
*-install targets, you should be OK.

However, this will be a problem for any binary package that is created,
as you suspected, as it will not be possible to run the binary package
on a system different to your own - the pathnames will not be correct. At
the moment, there's nothing that can be done about this. Sorry.

But a quick question - why does it hardcode paths in there? Can't scilab
use environment variables, or run-time checks, to make it much more

Take care,