[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sponsors.



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
as well.


> 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)


 - Hubert

-- 
NetBSD - because Unix isn't just #include <linux.h>, i386, ILP32, ELF, ...!


To unsubscribe: send mail to <majordomo@unixathome.org>
with "unsubscribe bsdports" in the body of the message