From: Jorge B. G. <yor...@gm...> - 2007-09-18 17:57:18
|
Hello, I'm updating the debian packages for fisterra, and changing same things on them. For example, I changed the rules script to use the cdbs system. Another thing I'm doing is splitting the packages. I divided libfisterra in libfisterra-common, libfisterra-client and libfisterra-server. In addition every lib* package has its lib*-dev, lib*-dbg and lib*-doc package. That division has its advantages. One can install only what really needs and nothing else,and a library can evolve independently of the others (the auth module could be upgraded and become binary incompatible with its previous version. If there's only one big package with all modules, every module must be upgraded without real changes. ). The problem comes with bmodules. There are 10 modules, most with 3 versions (common, client and server), and adding the -dev, -doc and -dbg packages, there will be near 100 packages. It can be really hard to work with that amount of packages. Not only for creating them, but for using them. There are scripts for creating them, and metapackages for using them but they are still a lot of packages. What do you think? Would be useful to have all that packages, or would be better to just have bmodules splitted in common, client and server packages? |