Hello,
On Jul 6 22:15 Till Kamppeter wrote (excerpt):
ippusbxd is a daemon to support IPP-over-USB printing
...
I am thinking about joining it into the cups-filters upstream package to not have too many tiny packages to make up the complete printing stack
What would be a real drawback of "many tiny packages"? Personally I would prefer "many tiny packages" because I favour the traditional KISS principle (to be read here as "keep it small and simple"). A consequence of the KISS principle is to keep separated things separated. "Keep separated things separated" is what I actually would like to have. For me it does not matter how big (or small) one single separated thing is. The basic reason why I think that separated things should be kept separated is that this makes it much easier to maintain all of them. I think it is easier to find volunteers who like to work on a single piece of their current personal interest when that piece of interest is provided as a separated piece of software that is (relavtively) easy to understand. In particular compile-time requirements are smaller for separated things which makes it easier to work on them (the edit->compile->install->test cycle is simpler). In contrast a big (possibly convoluted) all-in-one monster needs an universal genius who likes to tame such a beast. When separated things are kept separated it requires that interdependencies between those things are maintained. This is more work but it ensures that interdependencies are kept obvious. When separated things are kept separated one cannot accidentally make convoluted code full of hidden interdependencies that nobody understands after some time (i.e. where a fix here lets it break there). I assume ippusbxd is separated from the current cups-filters software so that - from my point of view - ippusbxd should be provided in its own "tiny package". For example - as far as I know - also cups-browsed is separated from the rest of the cups-filters software so that cups-browsed should be split from cups-filters into its own "tiny package". Also the backends in cups-filters are probably separated from the rest so that they could be split into their own "cups-backends" package. Strictly speaking each backend is separated from the other backends but having a separated package for each of them would be stretching it too far (cf. GNU coreutils). Assume different separated things all need some common funcionality (e.g. think about some common funcionality how to interact with CUPS). Then it would be cleaner when the common funcionality is not implemented independently in each of the separated things but split out into a separated "common funcionality" thing (e.g. a run-time library or as common source like Gnulib). Furthermore I assume that what starts as "tiny package" will grow over the time because usually more and more functionality will be added so that "tiny packages" usually become "normal packages". Imagine the final result when each of them would grow inside a single "all-in-one package". Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.lnx.2.00.1507070851290.23...@nelson.suse.de
