Date: Sat, 9 Sep 2000 00:37:43 -0500 From: Steve Price <sprice@hiwaay.net> To: Will Andrews <will@physics.purdue.edu> Cc: FreeBSD Ports <ports@FreeBSD.ORG> Subject: PortsNG (was Re: Ports Options Paper) Message-ID: <20000909003743.B92984@bonsai.hiwaay.net> In-Reply-To: <20000903052226.E1205@radon.gryphonsoft.com>; from will@physics.purdue.edu on Sun, Sep 03, 2000 at 05:22:26AM -0500 References: <20000903052226.E1205@radon.gryphonsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I go to a company picnic and drive my weary self home to find a flurry
of emails. I wish I had the energy left to address everyone's comments
but I still think we are not all rowing in the same direction so hopefully
I can voice my concerns with a single message.
I believe there to be one theme and that is that we need a better upgrade
mechanism. What we really haven't spelled out sufficiently in my mind is
what exactly it is that we want to achieve. I'll say it again. We need
to define in concrete terms what is good, bad, and needs fixin' with our
current system. Once everyone is on the same sheet of music, then and
only then can we start talking about how we design and code fixes.
Please let's forget about the 10 perl scripts, 3 acts of congress, and
2 acts of God for a few minutes. Let's define the problem fully first
and then start talking about ways in which we can address them. I have
a feeling that we'll come up with several distinct tasks that we can design
together and code in parallel. For instance, we'll probably end up
needing a better (read, more flexible) package format in the long run,
but we must define our expectations of it before we jump in and start
coding it otherwise we'll be back here next year doing the same thing.
If we ever get through hacking hacks that is.
Let's start by defining a wishlist[1]. I'll start with one very high on
my list. Let's say we have two ports of libfoo. The only difference
between them is that one is built WITH_BAR and the other without. If you
look at the pkgballs for each of these maybe 90% of the files in them
will be exactly the same. What I'd like to see is a way to have a base
(barebones) libfoo package and a satellite package with only the files
that change when built WITH_BAR.
Sounds pretty easy so let's take this one step further. Let's suppose
the same libfoo port is updated to a new version and now can also be
built WITH_ICK. Here's where it gets tricky. Are WITH_BAR and WITH_ICK
mutually exclusive or can both of them be on at the same time? If the
former then the new system needs to have the smarts to recognise that
there is a conflict and do 'something' about it. In the latter case
we need to have in place the infrastructure to build libfoo, libfoo_bar,
libfoo_ick, and libfoo_bar_ick.
Things like this are what we *must* nail down before we to decide to
pilfer, purchase, or code it ourselves. Am I the only one that feels
this way?
-steve
[1] For all you design purists you can read wishlist as vision statement.
A good vision statement is a precursor to defining requirements...
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?20000909003743.B92984>