Subject: Re: depends with wildcards in pkg_*
To: Alistair Crooks <email@example.com>
From: Hubert Feyrer <firstname.lastname@example.org>
Date: 09/09/1998 05:27:02
On Tue, 8 Sep 1998, Alistair Crooks wrote:
> Actually, currently, there are no DEPENDS or CONFLICTS with wildcards
> in them. We do plan to change this in the future.
Not now, but avoiding some damage right now doesn't hurt. :)
BTW, there's no problem w/ CONFLICTS and wildcards (as far as i can see),
as that's always passed to "pkg_info -e" (AFAICT).
> (a) a binary package on the localhost which can be used, as specified
> in a DEPENDS+= lesstif>=0.85.2 type of way, and
> (b) a binary package which should be fetched, if the DEPENDS+=
> lesstif>=0.85.2 type of matching in (a) above fails - at the moment,
> bsd.pkg.mk will go into the relevant directory at "make package" time,
> and grab the version number and place that in the @pkgdep field of the
> +CONTENTS file in the mozilla (or whatever) package.
So the test for the fildcard is actually only performed by bsd.pkg.mk, for
pkg_* there is one single versino hardcoded in the +CONTENTS file,
resulting in inconsistent behaviour between installing from source and
installing from binary. Which is no good, though.
> Now, personally, I believe we should combine the two, and record both
> in the +CONTENTS file, probably by using an extra @pkgmatch directive
> for (a). This will be done automatically at "make package" time.
I was thinking about something like this, too, but then i wondered why not
just write that wildcard/dewey match thing right into the @pkgdep line:
and use this pattern for detecting if it's already installed (using
pkg_info -e, as in bsd.pkg.mk), plus if it's not there, use the same
pattern to find a binary to install (in bsd.pkg.mk, that's the job of the
directory after the : in DEPENDS).
This functionality would (should... :-/) be independent of whether the
(dependent) binary pkg is installed from local harddisk or via FTP: It's
bot (as I outlined before...) to scan for a "best matching" pkg, and then
This "scanning for a best matching pkg" is quite easy when installing from
local disk, but via FTP, we'd need something to iterate over a directory,
which we don't have. In any case, it's going to some directory, looking
through all the binar pkg files present there, and picking the one that's
most appropriate to fulfil the dependency.
> Please note that this is completely separate from the +REQUIRED_BY
> file, which is a list of currently-installed packages on the
> localhost, and should never include any wildcards or dewey relational
Yes - +REQUIRED_BY would be handled if a depending package is upgraded
(e.g. xpm's +R is updated to match a new fvwm's version if fvwm is
What we still need now is some idea what to do with ftp-installs.
I'm clueless here - just ignoring it and heading for the "let's do it for
local disk installs and see after it later"-approach is something i'd
rather not do here (we just won't fix it after that, let's face it :).
Hubert Feyrer <email@example.com>