Date: Sat, 17 Feb 2001 01:32:57 -0800 From: Jordan Hubbard <jkh@winston.osd.bsdi.com> To: Mark Murray <mark@grondar.za> Cc: arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] Message-ID: <2628.982402377@winston.osd.bsdi.com> In-Reply-To: Message from Mark Murray <mark@grondar.za> of "Sat, 17 Feb 2001 09:32:59 %2B0200." <200102170732.f1H7WS952157@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
> We currently split the OS into two classes; src and ports. For a long
> time now I have had an idea for more of a continuum, and less of a
> dividing line.
>
> Basically it is this:
>
> The src and ports remain, but get redefined in a rather extreme way:
I think you're on the right general track, you're just not being
radical enough to reach the real prize at the bottom of this cereal
box. :-) [Note to self: Do countries other than the USA put prizes in
boxes of breakfast cereal? Must research this].
First, let me ask everyone to stop thinking about this in terms of the
traditional /usr/src and /usr/ports dichotomy and start thinking about
software from more of a 20,000 foot [6080 meter] level. When we talk
about software around here, we generally mean one of three things:
1. The aging binaries we got from some distribution medium in
pre-packaged form.
2. The binaries we just made ourselves using an automated build
mechanism which gave us very little clue as to what was actually
involved (and we like it that way).
3. The binaries we just made after doing open-heart surgery on some
collection of bits, hoping to see how successful the operation was.
Whichever of these 3 categories the bits may reside in, they also have
some common requirements: A sensible organizational structure
(taxonomy), a packaging scheme which makes it flexible and easy to
acquire the bits and a way of keeping those bits updated over the net
or from other media. The only thing which changes significantly in
each category is the amount of "source" you have around and I think
that one fact also pretty much shouts out the model we should be
looking at. But first, let's go back to that list of common
requirements.
To satisfy them, let's first assume that we have a really sensible
taxonomy for everything: The very minimum binary representation of
FreeBSD (/boot, /sbin, /bin, /etc), the text formatting tools, the
system libraries, the documentation, the toolchain, everything which
should be broken out into a sub-category or set of sub-categories is
properly identified and organized according to function. Let's also
assume that /usr/ports and /usr/src have been slammed together in our
global taxonomy and everything from "minFreeBSD" to "KDE 2" is
represented somewhere on the chart.
Finally, let's assume that we have fairly sophisticated packaging
tools which can package up everything from binaries to sources to "cvs
operations", e.g. the package extract actually results in a real-time
cvsup/anoncvs checkout operation rather than storing a snapshot of the
bits. Our updating tools would also be similarly capable of walking
through our tree of well-organized stuff and doing the right thing
automatically with some supplied update policy information. That's
all a bit more in the way of infrastructure than we have now, but
nothing completely out of the realm of reason to imagine our being
able to implement. Having to use sysinstall to install one set of
bits, pkg_add for another set and cvsup for yet another is part of the
problem here and a schism in desperate need of unification.
Getting back to the three listed categories, it's clear that for
category one, the binary package, the user will expect to simply "add"
the package and be done with it, no source being involved for the
trade-off of potentially getting an old set of bits (but maybe that's
the idea).
For category two, the automated build, "package add" could actually
result in the ports collection sequence of "go fetch some sources,
unpack them, build them, and install them." There's absolutely no
reason why some part of what we now traditionally think of as
"/usr/src" couldn't be a *transient* item if all you wanted sources
for was building binaries.
For category three, the developer actually interested in sources,
"package add" might mean "go cause these bits to be checked out of a
server somewhere or unpack them from the package itself as a source
snapshot [which can then be optionally updated later]." There's no
reason why a "source package" couldn't also be hacked on and then
checked back by a developer with a commit bit, it's all a question of
making the infrastructure support it. As long as the bits appear in
the appropriate places and the layout both makes sense and is
buildable, perhaps with other necessary components being checked out
on demand, all the advantages of a "static tree" are also maintained.
Tracking -current or tracking -stable also becomes largely a question of
what property you had set when you did your initial "pkg_add src-devel"
and that's all you need to know.
This also deals with long-standing religious wars over MTAs since
doing "pkg_add src-qmail" will result in the qmail sources being added
to the appropriate subdirectory of your source tree just like they
always belonged there, any subsequent change check-ins causing the
right thing to happen for that particular package. Maybe it gets
checked into a CVS sub-repository we maintain or maybe it simply gets
bundled up and submitted to the maintainer of qmail, many won't even
care which so long as the system works reasonably well.
In a design like this, all distinction between src and ports goes away
and it largely comes down to how much source the user wants to have
lying around - anything from all to none.
Developers adding new stuff to this system simply have to make sure
that it's properly fitted into the global hierachy and that it will
build and install correctly from its assigned spot, dependencies and
all. Whether its principal developer(s) then decide that the master
sources should live on primarily as a tarball or in a CVS repository
somewhere shouldn't be the end-user's concern at all. Just so long as
the components the user has declared transient on their system stay
transient and the components declared fixed have sources sitting in
the appropriate subdirectories of /foo/src whenever they look,
everybody is happy.
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2628.982402377>