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 would be too many resulting packages, which I
basically agree to.
So let's take a look a mirroring the (code) projects into the package
structure, we would get:
api
dba
documentation
external
framework
graphics
gsl
installation
l10n
oi (obsolet, but still used)
porting
qa
sc
script (obsolet, but still used)
sw
tools
ucb
udk
ui
util
whiteboard (obsolet, but still used)
xml
These are slightly more than in your suggestions (19 vs. 16), but still
seems to be manageable, the structure is partly similar. Benefits would be:
- Known package owner.
- No discussions where a new module belongs to etc.
- Already defined and established.
- Easy to find out where a module belongs too: cat module/CVS/Repository
Issues regarding build dependencies might give a hint about wrong module
placement and would need to be fixed anyway.
Comments?
Kay
It follows the module-to-project list:
api
bean
odk
offapi
offuh
oovbaapi
sdk_oo
udkapi
unodevtools
dba
connectivity
dbaccess
reportdesign
documentation
helpcontent2
external
MathMLDTD
addons
addons
afms
agg
apache-commons
beanshell
berkeleydb
boost
curl
epm
expat
external_images
fondu
freetype
hsqldb
icc
icu
jfreereport
jpeg
libegg
libtextcat
libwpd
libxml2
libxmlsec
libxslt
lpsolve
moz
msfontextract
neon
np_sdk
openssl
psprint_config
python
regexp
rhino
sane
stlport
tomcat
twain
unixODBC
vigra
x11_extensions
xalan
xpdf
zlib
framework
binfilter
desktop
embeddedobj
embedserv
filter
framework
idl
scripting
sfx2
unoxml
graphics
animations
avmedia
basegfx
chart2
goodies
sd
sdext
slideshow
svx
gsl
UnoControls
accessibility
basebmp
canvas
cppcanvas
dtrans
forms
fpicker
padmin
psprint
rsc
shell
sysui
toolkit
vcl
installation
extras
instsetoo_native
javainstaller2
packimages
postprocess
readlicense
scp2
setup_native
smoketestoo_native
wizards
l10n
i18npool
i18nutil
transex3
oi
sj2
porting
crashrep
sal
qa
qadevOOo
sc
sc
scaddins
sccomp
script
basctl
basic
xmlscript
sw
hwpfilter
linguistic
starmath
sw
swext
writerfilter
writerperfect
tools
autodoc
config_office
contrib
cosv
dmake
solenv
soltools
testshl2
udm
xml2cmp
ucb
store
ucb
ucbhelper
uui
udk
bridges
cli_ure
codemaker
cppu
cppuhelper
cpputools
idlc
javaunohelper
jurt
jvmaccess
jvmfwk
pyuno
rdbmaker
registry
remotebridges
ridljar
salhelper
stoc
testtools
unoil
ure
vos
ui
default_images
ooo_custom_images
util
automation
comphelper
configmgr
eventattacher
extensions
external
fileaccess
io
jut
o3tl
officecfg
sandbox
sot
svtools
tools
unotools
xmlhelp
whiteboard
lingucomponent
xml
oox
package
sax
xmerge
xmloff
xmlsecurity
Jan Holesovsky wrote:
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 hours. But
the build could be done nicely in parallel (on the level of machines, not
processors) if the sources were split correctly, with correct rpms and -devel
rpms [of course, applies to debs as well ;-)]. And of course, the -noarch
parts like the translations could be built just once for all architectures.
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 ooo-apps-calc
38M ooo-apps-extensions
14M ooo-apps-chart
40M ooo-apps-impress
40M ooo-apps-writer
59M ooo-artwork
107Mooo-filters
888Mooo-l10n
48M ooo-sdk
72M ooo-testing
(1.8G total)
(See below the content of these tarballs/archives). I don't want the
granularity to be too fine (we would get the modules we have now, but as
separate packages), and OTOH the current 5 packages are too few. The build
order of these would be:
ooo-bootstrap
ooo-libs-3rdparty
ure
ooo-libs-guitoolkit
ooo-libs-core
[the rest in whatever sequence/in parallel]
This would tremendously decrease the learning curve for the new developers as
well. Imagine someone who wants to start hacking on Calc. Instead of the
monster 1.8G sources, he would have to handle 512MB. Additionally, the goal
of the modern Linux distros should be to get rid of the ooo-libs-3rdparty
completely - it contains just stuff that is available from other sources
anyway [-system stuff], and the distros have packages for them -, thus
additional 142M down, doing
