[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Tue, Aug 29, 2000 at 01:59:52PM +0200, Hubert Feyrer wrote:
> Well, I'd like to find out how they differ, that's why I asked in the
> first place. :)
> What I know so far is:
> * OpenBSD has :L
> * NetBSD has :C///
fwiw, OpenBSD has :C/// as well ..
> > This could also be another issue...
> > Infact, anything that is run while building in the ports tree could be
> > different. I know FreeBSD at one point was using fetch, I know we have
> > fetch capacity in our ftp, etc ..
> A biggie that comes to my mind is 'perl'. NetBSD doesn't have it in-tree.
Hmm, several scripts in our ports tree rely on this fact. Although they
are not required to build a package that I can tell.. Is it reasonable
to expect a developer to have perl installed to build the ports tree? It is
akin to requiring someone to have tcl installed to build X. You must have
X to build tcl in the first place ;-)
> > > * Think about how to integrate this into existing OS'. I think something
> > > like the KAME project can act as an example here.
> > Yes and no. Do you realize KAME keeps a separate revision of each os
> > including a full kernel source tree? I don't think we want to keep a copy
> > of bsdports for each os .. or do we? Branches are ugly, ...
> Agreed - I guess we'll have to see. For the start I wouldn't mind having a
> disconnected bsdports tree, and later when everything's rolling,
> substitute the 'native' tree for the bsdports one.
Is this possible? With os release schedules and verification? Unless I'm
missing something, bsdports is intended to be a moving target. We failed to
make things work when trying to co-author the ports tree with FreeBSD simply
because of release scheduling and other related issues (as I recall ..) it
was purely technical (release needs) that caused us to have our own ports
> > There is an incredible amount of work to be done to decide what to keep and
> > what to merge and what to throw .. this cannot be understated .. not saying
> > I know there are things to throw, but surely in all the divergence over the
> > years, there have got to be incompatible 'features' and we can't just 'add
> > everything' .. in addition to the decision of how to re-integrate the work
> > into each os .. and if the sync'ing and creation overhead is more or less
> > work than maintaining a separate tree to begin with .. ;-(
> That's why we're at finding out features that we'd like to take, then see
> how they can be arranged together. E.g. 'make-maker' vs. 'fetch-list'.
> (I've had a closer look at your statement that 'fake-installs' make up for
> what we have as a bulk build framework, but I'm afraid that's not true.
> The latter takes care of rebuilding things only if needed, and the further
> cares about properly pkging up one thing - I can imagine they play
> together quite good)
Sounds like they're apples and oranges all right.
Suffice it to say, 'fake' allows for building all packages, even ones
that conflict, simply because it doesn't really do a 'true' install. It
just installs to a tmp dir, and creates the package from there. This also
enables 'flavors' .. and a much more guaranteed packing list (if you have
things that muck with installs in the Makefile, the packing list may not
Sounds like your bulk build stuff will keep disk space usage to a minimum
while building packages. A useful thing, and yes, it does sound like it
could easily play nicely with fake.
Here is a query. I'm going to nab NetBSD and FreeBSD pkgsrc/ports trees,
and see how a 'make fetch' then 'make' in archivers/ goes .. could someone
from FreeBSD and NetBSD try something similar? We might run into some
things we haven't yet covered.
The quick and easy anoncvs CVSROOT's:
:pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs ; co ports
:pserver:anoncvs@anoncvs.NetBSD.org:/cvsroot ; co pkgsrc
:pserver:anoncvs@anoncvs.OpenBSD.org:/cvs ; co ports
Todd Fries .. email@example.com
To unsubscribe: send mail to <firstname.lastname@example.org>
with "unsubscribe bsdports" in the body of the message