Re: RFS: qastools
>>> 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
Reply to: