On 2009-06-01 at 19:00:03 [+0200], Ryan Leavengood <leavengood@xxxxxxxxx> wrote: > On Mon, Jun 1, 2009 at 12:38 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> > wrote: > > > > The other eventual disadvantage would be needed customizations (like > > handling attributes in "mv" and "cp"), I really don't see a difference between those customizations being maintained as patches at HaikuPorts or in our repository. > > and/or testing of newer versions. Mmh, I don't understand this part. Someone would build a newer version, which, if it looks OK, would make it as updated optional package into Haiku. We could even have two or three stability levels for packages to choose from, so bleeding edge fans could always install the newest versions while others could select packages that have been tested a while already. > I think for something like that, especially something as "core" as mv > and cp we can just have them in our repo. This probably means pretty much all the *utils packages. > For testing new versions people would just need to update them as they > would any port. The updating would probably just be done by Haiku > developers instead of external porters. > > The cut-off for whether something is included in the repo could be > based on a combination of how core it is to the OS (FreeType and AGG > are pretty core, Mesa and vim maybe not so much) and also how big. I wasn't primarily thinking of libraries anyway, but the build system would support having those as packages, too. If we start outsourcing ported software, I'd first see how that goes for programs before considering libraries, though. > I > would never want to see WebKit in our repo for example. But maybe one > day it can become one of these mandatory packages if we have a > BHTMLView API or whatever. Yep. > > IMO, needing to install more packages would be acceptable as long as it > > would be done automatically when building Haiku (and if we maybe had a > > target that resolves all such dependencies without actually building > > Haiku). > > Automatic stuff is OK as long as there is a clear explanation of what > is going on when the "automagic" is happening. Plus we would need to > be sure our documentation was very clear on this as well. That wouldn't be a big problem, I guess. CU, Ingo