KDE 4 modules structure (again)

Adriaan de Groot adridg at cs.kun.nl
Sun Mar 14 16:45:30 GMT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 14 March 2004 17:19, Dominique Devriese wrote:
> Maks Orlovich writes:
> > That's only an advantage if you don't consider splitting of packages
> > to be a very bad idea, which in my experience as a Mandrake (which
> > first had monolythic packages, and then split them) user, it is, due
> > to much-much harder maintenance and administration (plus the
> > tendency of packagers to split stuff that really has 0 advantage of
> > being split).  At any rate, this is not an undisputably good thing
> > at all.
>
> 1 I am not talking about your life as a sysadmin, but packagers'
>   lives.

<neil>So the CVS admins and packagers should conspire together against the 
actual users of the packages?</neil>

> 2 The advantages of split distribution packages is an orthogonal
>   discussion, as packages are split by the packagers at the moment.  I
>   would argue that their benefits outweigh their disadvantages though.


Different thread, move along.

> Any particular reason why not ?  Or why we couldn't aggregate very
> small apps without any special dependencies in small modules again.
> These are things that can be discussed further along in the process.

You can't really _start_ the process untill a lot of later details are worked 
out, though. Is KFloppy to be a separately configurable and installable app? 
That needs to be decided now, since otherwise you end up with a kdeutils that 
is .. the same as kdeutils now.

> > 5. Increases the clean build time --- every single module needs to
> >    have configure genederate, configure run; doing this per-module
> >    is quicker than doing this per-application
>
> This is partly true, but its effects are not so bad because:
> 1 The amount of work that configure needs to do per-app will
>   decrease.

Finding maximum length of command-line args ... 524128

that takes a hell of a long time. The app-specific stuff in each configure 
seems to be pretty limited - basically, the content of the configure.in.in in 
the apps srcdir in the current setup. However, all the boilerplate needs to 
be done, as well as checking for a gob of extra libs all of a sudden (need to 
check for x-lib and y-lib and kdebase and kdelibs and kdelibs-woodchuck and 
kdelibs-2.6.14-ac3-pw1). 


- -- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <groot at kde.org>
                     Would you like a freem?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAVIwqdqzuAf6io/4RAsCGAJ9ikOVLAeGiX4PLXMkfwkJ3T6fyYACfYMKl
arlUaKAQWqpnnU4i5YWB/iU=
=6H/H
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list