From: API <api...@ig...> - 2007-09-28 06:13:14
|
> > Finally I followed an intermediate solution: instead of put each module in its > package, I splitted the modules in two categories: basic and extra. > > The basic modules are those that will be in every fisterra application for > sure (auth, calendar, document, payment and tax) and extra are the "optional" > packages (replication, uddi and migration). Each group has its > lib, -dbg, -doc and -dev package. > I think this is a good solution, because the modules in the basic group depend > on each other and they are used almost always together, and at the same time > we give more install options than all or nothing. > Anyway, if a particular module grows and it would be better in its own > package, it's better to split that package when that happens and not now. I think that this is a good idea. There are other projects that use this approach. For example, gstreamer, that have some packages that englobes several plugins (instead of one package for each plugin): gst-plugins-base gst-plugins-good gst-plugins-ugly gst-plugins-bad (Although probably, the last two packages are experimental packages, to include unstable or bad coded plugins) And about how split this ... well I think that only work with fisterra could show us the perfect groups of packages, but, uddi is a "optional" package? === API (api...@ig...) |