Date: Thu, 19 Oct 2000 21:34:55 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: Antoine Beaupre <beaupran@IRO.UMontreal.CA> Cc: questions@freebsd.org Subject: Re: Adding the package concept to the ports collection Message-ID: <14831.44879.402723.564087@guru.mired.org> In-Reply-To: <63199379@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Antoine Beaupre writes:
> I was wondering if it would be possible to add the 'package' concept to
> the ports collection in a sense that the database would include the name
> of the package or if there's none, why. An install target would then only
> have to download the package and save the compilation time. I also
> think that the package would be smaller than the source, and so, faster to
> download.
Yup, that's the advantages of packages. However, you can't go from
installing a port to installing packages. For instance, I set
LOCALBASE=/usr/opt in /etc/make.conf. A prebuilt package with
LOCALBASE=/usr/local won't work, because the libraries it's looking
for won't be in the right place, even though the dependencies are
met. Not to mention violating my system policies by installing what I
consider an optional part of FreeBSD(*) in /usr/local.
If you really want this, why don't you apply it to the port you're
working on, and install the package instead of the port? Once you've
got things set up right, it should all work as you describe. Caveat: I
don't use packages, and so have never done this.
> I think the port collection as it is now has several drawbacks, in terms
> of a software indexing facility, that is. Upgrading ports is a nightmare.
> The more we go, the more various ports have dependency lists that grow and
> grow. So when a single package such as GTK or ORBit gets updated, a whole
> chunk of ports have to be updated too. The problem is that
> "updated" means:
Well, the details aren't right (updating GTK may cause a package
dependent on it to be updated, but it doesn't mean you have to get the
new distfile for that package; just recompile it), but updating ports
is certainly a problem. In theory, it's pretty easy:
generate the dependency list for each package to be updated.
merge and tsort the lists of ports
foreach port in the list:
try:
make in <portdir>
pkg_delete the old version
except:
Tell the user it died and bail
reverse the port list
foreach port in the list:
try:
make install in <portdir>
except:
Tell the user it died and bail
Note that "pkg_version -c" tries to do this for you. However,
"pkg_version -c" has at least one serious problem. All my installed
packages are up to date - but I get *96* lines from "pkg_version -c",
because there are multiple versions of some of the ports. In some of
these cases, it just deinstalls and rebuilds the current port. In
some, it's going to upgrade a package where I'm running an older one
(which is still in the ports tree) on purpose. In the worst case -
well, consider this:
#
# glib
# multiple versions (index has 1.2.8,1.3.1)
#
cd /usr/ports/devel/glib13
make && pkg_delete -f glib-1.2.8
make install
It's going to delete my glib 1.3, and install 1.2!
I don't even want to think what it would have done if I'd had
japanese/w3m installed instead of www/w3m.
And right there is the root of the problem. A port name has two
selectors - the category and the name: www/w3m; sysutils/grub,
devel/glib13, etc. In that last case, the "name" is a composite of the
package name and the version. Packages just capture the name and
version, and don't notice when the version creeps into the name.
That's what kept me from turning the above pseudo code into a real
script: I couldn't figure out a reliable way to go from a package name
to a port name. I figure that the script wouldn't be much longer than
the pseudo, as a good HLL has most of the operations needed as
primitives or in a library. But getting that <portdir> is a pain. I
though briefly about trying to do this by grovelling through the ports
Makefile, but that's - well, you can see how well pkg_version does at
it.
> The problem with the current package system is that it does not resolve
> dependency problems by itself as the ports does. How could it anyways? A
> package is all it says: a package of information regarding a particular
> piece of software. It might include information on which other packages
> are needed by this one, but nothing else.
First, packages *do* include the dependency information. And what else
do you need? pkg_add will auto-install the required packages for you -
which is exactly what you're wanting it to do, right?
Come to that, if you don't believe that packages can do this job, then
there's no way you can make ports that load packages do it, as the
port may depend on a package that depends on things you don't have
installed. Once you fix that, you might as well just install the
package you're building instead of the port, and let the software that
deals with package technologies work there. Except it's already been
fixed, and packages behave like you want.
> Is it me or all this woudn't be that hard to implement? Just a PACKAGENAME
> variable along with a version variable of some sort (PORTVERSION would
> probably be OK) and a PACKAGE_SITE hierarchy of variables. That would be
> the biggest desgin problem...
The package system needs a rewrite before you can add a formal
"update" method for ports, which would be nice to have. If you're
going to do that, jkh has a wishlist for packages that include things
like an archive format with a directory, a secure scripting language,
a device-independent UI library, etc.
> I would be personnally ready to work on the ports for this to happen but I
> want to know wether or not this would be a good idea, or if there's
> already some work in pregress.
Ok, the right place to talk about ports is ports@freebsd.org. However,
this is a recurring topic there. Between that and it not being clear
about whether you wanted to work on packages or ports, I left the
discussion here. If you're wanting to work on the package system,
check with jkh. The interface library is being worked on, but I'm not
sure about the rest of it.
<mike
*) I know, I know - "ports aren't part of FreeBSD". I choose to
distinguish between locally written/installed software and them. You
should thank me - I'm helping keep the ports tree PREFIX-clean!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14831.44879.402723.564087>