Hi,
Probably it's not an issue, but I would expect Windows
people to find it easier to download one big tarball
than to go down hunting individual packages.
On the BSDs and linux we have the packages in one
place with many maintaners to help so it's not an
issue at all.
Cheers,
Pedro.
On Wed, 7 Sep 2011 09:48:35 -0700, "Dennis E. Hamilton"
<[email protected]> wrote:
Listing external dependencies seems important no matter what platform
we build for.
Why difficult for Windows? Explain please.
-----Original Message-----
From: Pedro F. Giffuni [mailto:[email protected]]
Sent: Wednesday, September 07, 2011 09:21
To: [email protected]
Subject: Re: Who wants to build OpenOffice?
FWIW,
The external sources include a lot of stuff that is
outdated and there may even be security risks involved.
I think I posted a list of outdated stuff before and
on FreeBSD I made sure we carry natively the latest
versions (with some care for compatibility).
Also there's the issue that was discussed already of
having an external ICU and dictionaries.
I do think that for linux/BSD distributions adding a
list of dependencies would just be better in the long
run, but that would make life more difficult for
Windows.
cheers,
Pedro.
--- On Wed, 9/7/11, Eike Rathke <[email protected]> wrote:
Hi Mathias,
On Wednesday, 2011-09-07 00:32:40 +0200, Mathias Bauer
wrote:
> >> 6) The bootstrap was pulling down
dependencies from Hg. We need to
> >> get those into SVN or Apache-Extras, right?
> >
> > Yes.
>
> Really? The "dependencies" (I assume these are the
external tarballs)
> are not stored in a Mercurial repo.
Correct, I just overread "hg" and concluded there needs to
be a place
for the external tarballs.
> Nevertheless we have to find a place
> for them - or to get back to the old procedure that
stored them inside
> the repo.
I wouldn't do that, being part of the repo we'd lose the
--with-external-tar=... capability and a checkout really
does not need
to include them.
> At least those that have a suitable license.
Of course.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private
communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96
2F1A D073 293C 05FD
