[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: