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 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 /CVS/Repository
>
> Issues regarding build dependencies might give a hint about wrong module
> placement and would need to be fixed anyway.
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 in them). What is the real problem from my
point of view is that currently you cannot take just one of the projects, and
(when you have the dependencies installed) self-containly build it. Also, if
you look at eg. framework, you see stuff that is essential for the OOo
functionality (desktop) as well as one that can be omitted (binfilter).
[Why do we need it: It would be great to have the .rpm/.deb/whatever packages
in accord with the build dependencies. It then allows us (the Linux
distributors) to build the packages in parallel easily. 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) do not have
to build everything up to Writer if you want to fix a Writer bug... The
Linux distros have mechanisms to install such development setups - eg.
'apt-get build-dep', or 'zypper build-deps-install' (to be in openSUSE
11.0).]
But the approach of moving the modules between the projects is generally OK
for me. Just let's be careful not to end up in arguments like 'X: This
module needs to be built in project A, that way we'll have the smallest
dependencies. Y: Yes, but people in the project B know most about it.' :-)
So - what can we do as the next step? Should I try to merge your and my list
to come up with the 'core' dependencies? Or could you, please?
Regards,
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
