Date: Sun, 19 Jul 1998 00:16:10 +1000 From: Sue Blake <sue@welearn.com.au> To: Chuck Robey <chuckr@Glue.umd.edu> Cc: freebsd-ports@FreeBSD.ORG Subject: Re: questions about packages Message-ID: <19980719001610.45098@welearn.com.au> In-Reply-To: <Pine.BSF.3.96.980718050959.18866M-100000@localhost>; from Chuck Robey on Sat, Jul 18, 1998 at 05:15:21AM -0400 References: <19980718171423.58388@welearn.com.au> <Pine.BSF.3.96.980718050959.18866M-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 18, 1998 at 05:15:21AM -0400, Chuck Robey wrote:
> On Sat, 18 Jul 1998, Sue Blake wrote:
>
> > I'm trying to fathom how packages work and there's a few things I can't
> > find in the documentation, or can't recognise if they're there.
> > Since this is in reference to a package for totally clueless newbies
> > I have no control over installation except from within the package itself.
> >
> > Here's the two questions I posted to -questions yesterday with little
> > result. An obvious third question is: How should one go about finding
> > out this kind of info?
> >
> >
> > Where does a package look to find the other packages it needs
> > that are not yet installed?
> >
> > How does it distinguish between another package that should be
> > installed if available, and a package that must be installed
> > before this one will install?
>
> Packages will check dependencies, but won't automatically go out, fetch,
> and install them. They'll just report missing pieces to the screen as a
> reasonably readable error message, and abort the package installation.
O...K... but consider kde-3.1b.tgz whose sole purpose in life is to pull
in a number of other packages until the whole of KDE is installed.
I know it works.
I don't know where it expects to find those other packages.
If they are not in that place, I don't know where else it looks.
If it can't find the other packages in any of those places, I'm not
100% sure whether it would install what it can with complaints, or
refuse to install anything. I need to be damn sure of this.
I'm not sure whether or not I can control these two behaviours from the package.
But I do know that it works.
> Probably most people using packages are doing it from the cdrom, so that
> just means doing an additional pkg_add with the name reported from the
> initial pkg_add, then repeating the initial pkg_add.
If my package needs to be on the cdrom to work brainlessly, then I have
to decide quickly whether to finish it within hours or wait until
October.
If my package does not need to be on the cdrom to work, ie, if it is
extremely simple for a windoze-oriented unix-ignorant person to
download it and have it find the packages on the cdrom, then I can use
less extreme time frames. But to do so would be excluding those people
for whom this was designed. I'm looking here at people who have
installed, typed DIR at the login: prompt, and wonder what to do next.
If they have already learned enough to set up ppp then half of the
package (as it stands) would be wasted on them.
> It's the _ports_ that automatically fetch, build, and install
> dependencies.
Sure. I would hope that a package wouldn't try to fetch (these people
will not have ppp up yet) but I have witnessed packages installing
dependencies. I could make it a port in order to make it fetch, but
that would change the target group of users and therefore nature of the
information it needs to deliver.
> Both ports and packages install a directory in /usr/db/pkg with the name
> of the application, and that directory has the information needed later
> to do an uninstall. One can always (if you want) use pkg_info to
> pre-check for dependencies. Pkg_info won't install anything, so it's
> safe to use.
Well, I'm creating, not installing, and the people who will be
installing won't be investigating those things. They'll be taking ten
minutes to find the right keys to type in 'pkg_add filename' correctly,
and have neither the knowledge nor enthusiasm to investigate further.
*After* the package is installed they will have the means to *begin* to
learn these things. Meanwhile, I have to make sure I know damn well how
that package works in order to give them some chance of success with
no prior knowledge and the minimum of keystrokes.
--
Regards,
-*Sue*-
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980719001610.45098>