RE: Ports/Source Issues
> This is essentially what the ports collection does for FreeBSD.
> You can use it to build packages from source and manage packages
> to some extent. What you are talking about (forgive me for
> being a Debian newbie) is putting together an automated .deb
> build tree. You have something similar to this already right?
> Is it up somewhere the rest of us could poke at it and see
> what it does and doesn't do already?
>
Well, I don't think our system correlates to the port process
very well. Debian's system views the "world" of software in
the archive as a set of separate entitites. There are relationships
between the various entities that indicate that one package might
"require" another package to function (like certain libraries),
or some package might "recommend" another as being useful to it.
On the source side, things are a little more nebulous. Basically,
the source for the binary packages live in a tree that roughly mirrors
that of the binary archive. Sometimes source packages build more
than one binary package, so it's not a perfect 1:1 relationship.
Our autobuilders are designed to handle single packages -- so we
don't have the ability to walk down a tree and build the entire
distributions -- or rather, we don't have that ability without
running a control process to re-run the autobuilder for each
package in its queue.
> # My initial thought is that we should base such an animal on
> # Debian's existing source+diff methods, with perhaps a bit more
> # checking for system requirements (libraries, tools, etc.) This
> # would allow us to eventually allow dselect/apt to administer
> # a set of binary and source packages on a BSD (and even Linux)
> # system.
>
> How are dependencies currently handled? If I grab the source
> and diffs and build a program myself will all the dependencies
> be sucked in, built, and installed for me? Do they get sucked
> in as .debs or will they also be built from source?
>
Not in its current state -- that's why I mention having to develop
a Debian Policy for this. When you install a binary, all
dependencies are provided. But the source packages assume some
level of knowledge on the part of the user -- you need to have
the right tools in place or the build fails.
What I am suggesting as a first step (for Debian) is to lay
out what dependencies (and how) come with a source package.
The infrastructure is in place -- it just hasn't ever been
an issue up to now.
> # I am invisioning a system that could maintain version and
> # dependency information about the entire state of the system
> # even if some of the system was binary installed, and some
> # consisted of source packages.
>
> Shouldn't the source package and binary package be separate?
> I mean if I install the source package it doesn't mean other
> packages can use the binaries from it until I've actually
> built and installed what it produces, which is much different
> than me having installed the source for it. Correct?
>
Yes. I guess what I was thinking is that the source package
might build during the install process. I.e., the source would
arrive on a non-programmer's system, it would open up and build
itself, then install the software (without the user's interaction
except for some prompting regarding options, etc.)
If what you want is a means to install the source as a
separate entity from installing binary software, then our
system already does that. We have "source packages" right now
(for instance the Linux Kernel packages) that install in
/usr/src and provide tools to help the user build them.
However, to date these have been package-specific, and really
almost kernel-specific and help install the package, etc. These
could be generalized to provide a bit better utility.
> Would your proposed method of building from source install
> the necessary package management cruft somewhere during the
> build process for the binary package it just installed?
>
Yes. Currently, the debian "diff" to a source tarball includes
just such management data. So, when a source package reaches
the "install" step, it would update the database, package lists,
etc. and become a "live" part of the system.
> # Hamish, this might dovetail well with some recent traffic on
> # Debian-devel asking about optimized-compiles for various
> # architectures. Certain packages could be distributed as
> # binary or source -- with the source version doing a self-
> # compile on the user's machine. This would allow users to
> # "twist knobs" (as Steve Price puts it ;) ) and customize things
> # to their liking.
>
> What would also be nice is to have all the source stuff together
> in one place so that the strong-willed, sick individuals among
> us, could pull them all down at one time as builds the one we
> want and use the rest for reference as we create new ones. :)
>
Yes -- and very easily done as well. (It save's the delete step!)
The only danger is in disk space -- which is another reason some
might opt to use primarily binary packages, and just install
source for items of particular interest to them.
> # This could be a real advantage for both BSD and Debian GNU/Linux,
> # and would perhaps be the first "fruit" of this effort.
>
> Though not perfect you might want to take a look at the file
> /usr/ports/Mk/bsd.port.mk on a FreeBSD machine. This is all
I probably need to switch my Hurd machine to FreeBSD and start
playing with this some more. My lack of experience with BSD's
features is becomeing a larger problem! ;-)
-Brent
Reply to: