[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Tue, 29 Aug 2000, Todd T. Fries wrote:
> I hate to suggest this, but we'll either want to maintain an in-bsdports-tree
> make, or have each os try to build the other's ports tree and see what
> 'features' are missing .. if this is even a good way to do so ..
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///
I don't know what else, but there sure is a much longer list of
differences in the OS. I'd take "making all make(1)s do the same"
as a long term goal, esp. as we'll need it for porting to non-BSD
> Has everyone upgraded to egcs-2.95.2 ?
No. We're migrating to it, but the upcoming 1.5 release won't have it.
There are just too many platforms we need to care for.
> 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.
> > * Get the remaining features implemented in bsd*mk, pkg_* and the
> > pkgs/ports themselve
> don't forget make ..
right, probably some others
> > * 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.
> 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)
NetBSD - because Unix isn't just #include <linux.h>, i386, ILP32, ELF, ...!
To unsubscribe: send mail to <firstname.lastname@example.org>
with "unsubscribe bsdports" in the body of the message