Date: Mon, 20 Jul 1998 19:03:02 +1000 From: Sue Blake <sue@welearn.com.au> To: Tim Vanderhoek <ac199@hwcn.org> Cc: freebsd-ports@FreeBSD.ORG Subject: Re: questions about packages Message-ID: <19980720190302.26824@welearn.com.au> In-Reply-To: <19980719114655.A20943@zappo>; from Tim Vanderhoek on Sun, Jul 19, 1998 at 11:46:55AM -0400 References: <19980718171423.58388@welearn.com.au> <Pine.BSF.3.96.980718050959.18866M-100000@localhost> <19980719001610.45098@welearn.com.au> <19980718134825.C11959@zappo> <19980719082019.63071@welearn.com.au> <19980718175516.A18192@zappo> <19980719111914.25963@welearn.com.au> <19980719072000.B20184@zappo> <19980720011454.23919@welearn.com.au> <19980719114655.A20943@zappo>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 19, 1998 at 11:46:55AM -0400, Tim Vanderhoek wrote:
> On Mon, Jul 20, 1998 at 01:14:54AM +1000, Sue Blake wrote:
> >
> I really think that if you want a package, then you should be going
> about this by using an install or requirements script for the package.
Yeah, a package isn't meant to handle this kind of job without a fair
bit of help from a script. Maybe I don't need a package after all. It
feels like using one tool to undo the work of another, which usually
means the wrong first choice.
> That allows you to test for any possible error condition you can
> dream-up, and then handle the condition in the most graceful way that
> a newbie could want.
OK, I've got a package that works pretty well in a limited range of
circumstances with pkg_add's current default -f behaviour but won't
work at all if pkg_add is fixed. Now I want more: some control over how
pkg_add runs without giving pkg_add the final say on failure of the
whole kaboodle over some trivial or essential dependency, more
flexible, less trusting, maybe interactive. That's going to need a very
different (mental) approach. I'll probably come up with a package again
somewhere down the track but as an end point, not as a starting point.
That'll keep me out of -ports for a while :-)
> > The person creating the package has no way to change it, and the person
> > installing has no way to predict its default behaviour. In fact, nobody
> > seems to be real sure where it looks. I'm sure I can hear pkg_add
>
> Well, I did try to tell you where it looks... :)
I wasn't convinced... I gave unpredicted examples... and then you
agreed and said but don't trust it :-)
> [Re: dependency-failed-error]
> > My current vote says it's not intended to be soft, but it is, and I
> > like it that way. It tells me a package is installed (and can't be
>
> It probably should be fatal unless -f is specified, IMO...
I agree. However if it is "fixed" to work as advertised, then minicom
and similar packages will need to be changed, otherwise they'll
suddenly start bombing out for anybody without an Internet connection.
At the moment minicom seems to rely on pkg_add erroneously proceeding
when kermit is not found.
> > It seems to me that for inexperienced FreeBSD users:
> > A package which has no dependencies is always easy and convenient to use.
> > A package which has dependencies is too difficult and unpredictable unless
> > it's on the CD with the others.
>
> Yup. That's why I'm still suggesting an install or requirements
> script. :) Or even just a plain script, for that matter. Do you
> have any familiarity with dialog(1)? Can have a lot of fun with a
> "plain script"... ;)
Ooooh... I had a look at the man page and although I can't work it out
from that, it looks tempting. Where can I get to see some examples
of how it's used?
> > In a couple of weeks there will be (hopefully many) people creating
> > packages with dependencies for the xcontest, and they will have to deal
> > with the same issues (or misconceptions?) that I'm raising now. It'd be
> > nice to have answers ready for them too.
>
> Well, those packages are allowed to assume reasonable competency and
> reasonable setup on the behalf of the user, which really solves the
> whole problem... :)
Oh, right, I misunderstood. I thought the xcontest was to come up with
an easy setup for a new user's first encounter with FreeBSD.
--
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?19980720190302.26824>