[haiku-development] Re: Outsourcing more command line apps to optionalpacakges

Hi,

Am 13.10.2010 20:41, schrieb Ingo Weinhold:
On 2010-10-13 at 18:46:13 [+0200], scott mc<scottmc2@xxxxxxxxx>  wrote:
2010/10/13 Jérôme Duval<korli@xxxxxxxxxxxxxxxx>:
2010/10/13 Stephan Assmus<superstippi@xxxxxx>:
With vi, did it compile out of the box or does it still require
patches? IMO if packages compile out of the box, then they can be
moved out of our repository. If they cannot, having them in our svn
repository is a very safe patch storage mechanism.

I share this opinion. Also don't forget that it makes the life easier for
whoever works on other target architectures.

Same here. From the ones listed above, I know coreutils requires
patchs which we probably need to maintain in our repository.

The problem I see with putting the patched files into our tree is that
the patches are then not so easy to locate.  Then when the package
gets updated there's no patch file to look at since the patch was
integrated into the source in Haiku.  The way patches are handled at
HaikuPorts is that they are kept as patch files until they are
accepted and applied upstream, at which point our chances of the next
revision/version being released, being able to "just build" on Haiku
are a greater.

I totally agree. HaikuPorts is suited way better to deal with ports.
Furthermore having the ports in the Haiku repository isn't for free either.
Besides that this stuff increases the weight of the repository as well as the
build times significantly, it's also more work and more error prone to
maintain and update the ports, since the integration with our build system
and the manually maintained config.h files is simply not how the ports are
meant to be built. That has caused problems more than once in the past.

Moreover most software packages come with test suites, which are blatantly
ignored when we just build things in the Haiku build system. When ports are
updated at HaikuPorts the tests are actually run and failures are being
tracked.

[...]

I guess most actually can be outsourced. The only one I can think of ATM that
wouldn't be trivial to is gdb, since it uses private APIs. But I was hoping
to get rid of it anyway once Debugger is in a usable shape.

[...]

For what it's worth, you convinced me. :-)

Best regards,
-Stephan

Other related posts: