>>> Why regroup qasmixer and qasconfig into one package? Wouldn't it be >>> better having them Recommend each other? It doesn't seem like an >>> improvement forcing users to install both tools instead of giving them >>> the choice. But maybe I'm missing something. >> >> The short answer is, it makes package maintenance much easier and >> is less error prone. > > I see the point of having one source package for all the tools, but you > could still make several binary packages from there (as alsa-tools does, > though not for every single utility I must admit).
I've thought about multiple packages, too. A setup like this should work: qastools-common - Shared stuff ( l10n, etc. ) qastools-qasconfig - Config app qastools-qashctl - HCTL Mixer app qastools-qasmixer - Mixer app That would require a patch to the root CMakelists.txt for each package but it should be a trivial. The esscence there is: ADD_SUBDIRECTORY ( i18n ) ADD_SUBDIRECTORY ( qasconfig ) ADD_SUBDIRECTORY ( qashctl ) ADD_SUBDIRECTORY ( qasmixer ) Three of the four would have be commented out for each package. Thinking about it this looks better to me than the collection package. Do you think this is a reasonable setup? I haven't worked with quilt yet, but will look into it. >> A somewhat longer explanation includes: >> >> 1. All QasTools share certain amounts of code. But it's not worth it >> creating a library package (with all the hassles) for that. >> >> 2. All QasTools share a single localization database (app_xy.qm). >> It's a pain to organize translations for a small application. >> A single translation file for a small number of applications is >> much easier to deal with for translators and maintainers. >> >> 3. QasTools may grow by a few applications. It's very likely that >> potential users will install/use more than one of them anyway. >> The applications themselves are not very large. >> >> 4. This goes in the tradition of alsa-tools, alsa-tools-gui and >> alsa-utils. They all bring a small number of applications wich >> cover certain aspects of ALSA. >> >> I hope this makes it a bit more clear. > > Those seem like perfectly valid reasons, and it does make it clearer, > thanks. Might be worth including the gist of it in the debian/changelog, > so that users who wonder about the change can find the reason easily. Actually, some of this could on the web site, too. :) Regards, Sebastian -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee7829f.5020...@gmx.de