[haiku-development] Re: Removing ported code from the repository, replacing with prebuilt packages (was: [haiku-commits] r35705)

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 04 Mar 2010 10:14:34 +0100

On 2010-03-03 at 19:28:28 [+0100], Matt Madia <mattmadia@xxxxxxxxx> wrote:
[...]
> I'll try summing it up here, to help refresh everyone and bring new
> people up to speed.
> 
> Pros:
>  * makes the repository file size smaller
>  * reduces build time
>  * reduces maintenance work
> 
> Cons:
>  * repository would no longer be self-contained
>  * those packages would need to be downloaded via build system
>  * for ports to other architectures one would have to cross-compile the 
>  software
>  * needed customizations (like handling attributes in "mv" and "cp")
>    x What's the difference between those customizations living in our
> repository or HaikuPorts?

None, really.

>  * testing of newer versions of prebuilt packages
>    x currently needed for OptionalPackages
>    x could introduce 3 stability levels of prebuilt packages
> 
> Misc Conditions:
>  * first outsource ported programs as trial basis. depending on that,
> consider libraries.
>  * 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).

I envision a build profile action for downloading (jam -q @alpha-raw 
download).

>  * for something as "core" as `mv` and `cp`, we can just have them in our 
>  repo.

I don't see much difference to, say, sed. If we break self-containedness of 
the build, we can as well do it thoroughly. That would include the even more 
"core" bash.

A criterion for outsourcing should be that the package in question can be 
cross-compiled. If that is not possible, it would be a major pain for 
architecture ports.

CU, Ingo

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2010