Hi Mathias,
On Wednesday 30 of April 2008, Mathias Bauer wrote:
> > Well, my _only_ motivation for the split are the build dependencies - so
> > if we end up with 20 (sub)packages, or 15, I don't really care :-) Also,
> > the names are not that big deal for me (though I personally prefer better
Jan Holesovsky wrote:
> Well, my _only_ motivation for the split are the build dependencies - so if
> we
> end up with 20 (sub)packages, or 15, I don't really care :-) Also, the names
> are not that big deal for me (though I personally prefer better describing
> names, and a kind of structure
Caolan McNamara wrote:
On Mon, 2008-04-28 at 20:25 +0200, Jan Holesovsky wrote:
Another advantage is that it is also easy for the potential
contributors to install just the
-devel packages of the dependencies, and start with the development in
the package where he/she wants to fix something -
Hi Jan,
Jan Holesovsky wrote:
Well, my _only_ motivation for the split are the build dependencies - so if we
end up with 20 (sub)packages, or 15, I don't really care :-) Also, the names
are not that big deal for me (though I personally prefer better describing
names, and a kind of structure
On Mon, 2008-04-28 at 20:25 +0200, Jan Holesovsky wrote:
> Another advantage is that it is also easy for the potential
> contributors to install just the
> -devel packages of the dependencies, and start with the development in
> the package where he/she wants to fix something - eg. you (generally
Hi Kay,
Apparently I missed your mail - sorry for that :-(
On Wednesday 09 April 2008 15:35, Kay Ramme - Sun Germany - Hamburg wrote:
> just wanted to suggest that re-using one or the other already existing
> structure for package re-organization would have some benefits. Possible
> candidates I
Hi Jan,
just wanted to suggest that re-using one or the other already existing
structure for package re-organization would have some benefits. Possible
candidates IMHO are:
-1- projects
-2- modules
You more or less already ruled out the modules approach, arguing along
the line, that it woul
Matthias Klose wrote:
Stephan Bergmann schrieb:
Jan Holesovsky wrote:
Keep in mind that the current situation is that some 3rdparty stuff
checked into OOo is either/both:
- accompanied by patch files to adapt to OOo requirements,
- required by OOo in specific versions.
So, in general, with
Stephan Bergmann schrieb:
> Jan Holesovsky wrote:
> Keep in mind that the current situation is that some 3rdparty stuff
> checked into OOo is either/both:
>
> - accompanied by patch files to adapt to OOo requirements,
>
> - required by OOo in specific versions.
>
> So, in general, without clean
Hi Stephan,
On Thursday 01 of November 2007, Stephan Bergmann wrote:
> > My vision is that on modern Linux distros, you won't need
> > ooo-libs-3rdparty at all, because you will have all the packages in the
> > distro already, and you'll be able to install them from there (most
> > probably with
Jan Holesovsky wrote:
Hi Martin,
On Friday 12 October 2007 12:37, Martin Hollmichel wrote:
Eg. the spellchecker (hunspell) itself is in the lingucomponent which I
propose to put to ooo-apps-extensions (and thus to ship it together with
the application). The dictionaries for it are in
ooo-libs
Hi Mathias,
On Tuesday 16 October 2007 10:12, Mathias Bauer wrote:
> As we are currently talking about splitting up the source I think it
> makes most sense to have separate builds for each extension.
Again I am a bit afraid of too fine granularity in the case 1 extension = one
tarball. But we
Hi mathias
The point is that people want to get rid of the "whole process". That
doesn't mean that we won't be able to build everything in one step but
that shouldn't be the only way to build something that is part of the
OOo code base.
Thanks for your development
laurent
--
Laurent Godard
Hi Mathias,
On Monday 15 October 2007 17:45, Mathias Bauer wrote:
> The advantage of one single "3rdparty" package is that you either can
> use it as a "make yourself happy with one click" package or you don't
> use it at all and use each library as part of the already available 3rd
> party packa
Laurent Godard wrote:
> Hi Mathias, Hi Martin
>
>>> just stumbled about that the report design extension is built during the
>>> regular build process, wouldn't it be better at all to create a source
>>> tarball include jfreereport and reportdesign modules. Where we already
>>> achieved modula
Hi Kendy,
Jan Holesovsky wrote:
> Hi Mathias,
>
> On Friday 12 October 2007 20:18, Mathias Bauer wrote:
>
>> > just stumbled about that the report design extension is built during the
>> > regular build process, wouldn't it be better at all to create a source
>> > tarball include jfreereport an
Laurent Godard wrote:
Hi Mathias, Hi Martin
just stumbled about that the report design extension is built during
the regular build process, wouldn't it be better at all to create a
source tarball include jfreereport and reportdesign modules. Where we
already achieved modularization in the sou
Jan Holesovsky wrote:
> Hi Martin,
>
> On Monday 15 October 2007 14:11, Martin Hollmichel wrote:
>
>> > But for the Win32 builders, searching for the dependencies
>> > could be too expensive - that's why I propose the 'super-source-package'
>> > ;-) Of course, we can go the way of ooo-3rdparty-
Hi Mathias, Hi Martin
just stumbled about that the report design extension is built during the
regular build process, wouldn't it be better at all to create a source
tarball include jfreereport and reportdesign modules. Where we already
achieved modularization in the sources we should IHMO als
Hi Martin,
On Monday 15 October 2007 14:11, Martin Hollmichel wrote:
> > But for the Win32 builders, searching for the dependencies
> > could be too expensive - that's why I propose the 'super-source-package'
> > ;-) Of course, we can go the way of ooo-3rdparty-dictionaries,
> > ooo-3rdparty-epm
Jan Holesovsky wrote:
Hi Mathias,
On Friday 12 October 2007 20:18, Mathias Bauer wrote:
just stumbled about that the report design extension is built during the
regular build process, wouldn't it be better at all to create a source
tarball include jfreereport and reportdesign modules. Where we
Hi Martin,
On Friday 12 October 2007 12:37, Martin Hollmichel wrote:
> > Eg. the spellchecker (hunspell) itself is in the lingucomponent which I
> > propose to put to ooo-apps-extensions (and thus to ship it together with
> > the application). The dictionaries for it are in
> > ooo-libs-3rdparty
Hi Mathias,
On Friday 12 October 2007 20:18, Mathias Bauer wrote:
> > just stumbled about that the report design extension is built during the
> > regular build process, wouldn't it be better at all to create a source
> > tarball include jfreereport and reportdesign modules. Where we already
> >
Jan Holesovsky schrieb:
> Oh, sure! My original mail contains my suggestion of what belongs where -
> please have a look, input is most appreciated. I did few corrections
> afterwards (accessibility, bean, crashrep, and package moved to
> ooo-apps-extensions, jut moved to ure, rvpapi removed,
Martin Hollmichel schrieb:
> Hi,
>
> just stumbled about that the report design extension is built during the
> regular build process, wouldn't it be better at all to create a source
> tarball include jfreereport and reportdesign modules. Where we already
> achieved modularization in the sourc
Rüdiger Timm schrieb:
> I am not against having the possibility to get smaller, logically
> connected parts of the code base separately. What I do not want (and
> perhaps that was a misinterpretation of the original posting) is having
> different parts in different, distinct archives.
Of cours
Hi,
just stumbled about that the report design extension is built during the
regular build process, wouldn't it be better at all to create a source
tarball include jfreereport and reportdesign modules. Where we already
achieved modularization in the sources we should IHMO also do the right
pa
Jan Holesovsky wrote:
Eg. the spellchecker (hunspell) itself is in the lingucomponent which I
propose to put to ooo-apps-extensions (and thus to ship it together with the
application). The dictionaries for it are in ooo-libs-3rdparty/dictionaries
- the distros have their own packages, but it s
Hi Mathias,
On Wednesday 10 October 2007 21:14, Mathias Bauer wrote:
> > Personally, I do not like spitting up sources at all. But that's my very
> > personal opinion.
>
> Splitting up source definitely is a good idea. Maybe not for people
> building everything anyway but it would be a huge step
On Thu, 2007-10-11 at 09:05 +0200, Rüdiger Timm wrote:
> My feeling is we should first do some work on our code base so that be
> really can benefit from a split.
Perhaps a good case study of such a split is the modular X effort which
broke the monolithic x.org build into separately buildable pr
Mathias Bauer wrote:
Rüdiger Timm wrote:
Personally, I do not like spitting up sources at all. But that's my very
personal opinion.
Splitting up source definitely is a good idea. Maybe not for people
building everything anyway but it would be a huge step ahead for the
casual developer like
Rüdiger Timm wrote:
> Personally, I do not like spitting up sources at all. But that's my very
> personal opinion.
Splitting up source definitely is a good idea. Maybe not for people
building everything anyway but it would be a huge step ahead for the
casual developer like volunteers, distro mai
Jan Holesovsky wrote:
Hi Ruediger,
I am sorry, I missed a part of the mail when I was answering previously :-(
No problem.
On Monday 08 October 2007 17:36, Rüdiger Timm wrote:
This would tremendously decrease the learning curve for the new
developers as well. Imagine someone who wants
Hi Ruediger,
I am sorry, I missed a part of the mail when I was answering previously :-(
On Monday 08 October 2007 17:36, Rüdiger Timm wrote:
> > This would tremendously decrease the learning curve for the new
> > developers as well. Imagine someone who wants to start hacking on Calc.
> > Inst
Hi Shaun,
On Monday 08 October 2007 21:14, Shaun McDonald wrote:
> > [...] And of course, the -noarch
> > parts like the translations could be built just once for all
> > architectures.
>
> Language packs are currently system specific. Thus building once for
> all archs is not currently possible
On 8 Oct 2007, at 13:57, Jan Holesovsky wrote:
Hi,
[...] And of course, the -noarch
parts like the translations could be built just once for all
architectures.
Language packs are currently system specific. Thus building once for
all archs is not currently possible. This would require
Hi Ruediger,
On Monday 08 October 2007 17:36, Rüdiger Timm wrote:
> > During the OOoCon, Petr had a presentation about the OOo package
> > splitting. The most important part for a (Linux) package maintainer was
> > to be able to build parts of OpenOffice.org separately; the thing is that
> > with
Jan Holesovsky wrote:
Hi,
Hi Jan,
During the OOoCon, Petr had a presentation about the OOo package splitting.
The most important part for a (Linux) package maintainer was to be able to
build parts of OpenOffice.org separately; the thing is that with all the
localizations, we are unable
On Monday 08 October 2007 14:57, Jan Holesovsky wrote:
> I propose the following split of the sources [the sizes are of the unpacked
> sources]:
>
> 75M ure
> 25M ooo-bootstrap
> 141Mooo-libs-core
> 101Mooo-libs-guitoolkit
> 142Mooo-libs-3rdparty
> 17M ooo-apps-base
> 28M
Hi,
During the OOoCon, Petr had a presentation about the OOo package splitting.
The most important part for a (Linux) package maintainer was to be able to
build parts of OpenOffice.org separately; the thing is that with all the
localizations, we are unable to get the build times under some 7 h
40 matches
Mail list logo
