Ethereal-dev: RE: [Ethereal-dev] error in Solaris install

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "HOOD, Andy" <ahood@xxxxxxxxxxxxxx>
Date: Wed, 22 Oct 2003 19:00:21 +1000
Can't you just set the package root to /usr/local, package any things that
belong in /other/locations in there temporarily, and have pkgadd relocate
them?

Regards,
Andrew Hood
A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable. -- Leslie Lamport,
as quoted in CACM, June 1992



 -----Original Message-----
From: Biot Olivier


Hi all,

I record at least one pkgadd patch in the recent 1-2 years, resulting in
correct installation before and incorrect installation after applying this
OS patch. This was true for other Solaris, packages too, which were
rewritten because of this odd behavior.

I would propose to perform some checks in the PREINSTALL section of the
package, and remove the requirements on "/usr/local/bin" and other being
directories. This implies that those directories will have to be removed
from the package map. Maybe the preinstall script should test whether the
target directory exists, and whether it is a directory and not a symlink. If
both checks yield a positive answer, then normal installation will proceed.
Otherwise present extra information to the installing user, allowing either
another target DIRECTORY (not a symlink) or let the script create the
missing directory (/usr/local).

Regards,

Olivier
 -----Original Message-----
From: Alex Fontana

Jeff Morriss wrote:
Gerald Combs wrote:
> On Mon, 20 Oct 2003, Alex Fontana wrote:
>
>
>>I recently installed ethereal-0.9.15-solaris2.8-sparc-local off the local
archive, and I found that it destroyed my /usr/local/bin and /usr/local/lib
directories.  Fortunately these were only symlinks, but I thought you guys
might want to know.
>
>
> "Destroyed" in what sense?  Were the actual directories that
> /usr/local/bin and /usr/local/lib point to affected in any way?
>
In my case, /usr/local/bin was a symlink to /usr/local/packages/local/bin,
and /usr/local/lib was set up similarly.  The install removed the symlinks,
and replaced them with new directories.

> The package information (prototype(4)) file used to create the packages 
> has the following entries:
>
> d none /usr/local/lib 0755 root bin
> d none /usr/local/bin 0755 root bin
>
> The "d" at the beginning of each line indicates that each item should
> be a directory.  Apparently the Solaris package installer _really_ wants
> these to be directories, and clobbers anything that's not a directory with
> the same name.  It looks like other people have run into this behavior: 
>
>     http://groups.google.com/groups?&selm=x71yyu3mkg.fsf%40mitra.com
>     http://groups.google.com/groups?th=38827a44f2e2b6f5
>
> I'm not sure this can be fixed on our end.  Removing /usr/local/lib and 
> /usr/local/bin from the prototype file would break the installation on
> systems that don't have those directories.
 
I'd be pretty surprised if it were not possible for the package installer to
avoid destroying symlinks.  I'm not that familiar with the Solaris package
installer, though.  You may be able to just assume that /usr/local/bin and
/usr/local/lib already exist (perhaps as dependencies)?

I *think* I've seen that Solaris' 'pkgadd' will still install if some
directories don't exist (and aren't in the pkgmap), but it will issue a
warning about an "implied directory" or some such...  (Don't know what
it would do about permissions, though.)

<<application/ms-tnef>>