[oe] [meta-qt5][PATCH v2 05/11] qt5: disable debian auto renaming

Samuli Piippo samuli.piippo at theqtcompany.com
Thu Sep 3 13:10:49 UTC 2015


On 02.09.2015 20:53, Otavio Salvador wrote:
> On Wed, Sep 2, 2015 at 2:25 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
>> On Wed, Sep 02, 2015 at 02:07:15PM -0300, Otavio Salvador wrote:
>>> On Tue, Aug 25, 2015 at 8:43 AM, Samuli Piippo
>>> <samuli.piippo at theqtcompany.com> wrote:
>>>> Some of the Qt modules have multiple libs, which prevents debian auto
>>>> renaming to work correctly. Instead of only having some modules renamed,
>>>> disable renaming for all Qt module packages, so that all they all are
>>>> named as ${PN}.
>>
>> I don't think this explanation is good enough reason to disable debian
>> renaming and that's why I didn't take it into master-next yet.
>>
>> The original idea was to let qt5 package with libraries coexist with qt4
>> ones, I agree that not many people are using this, but on the other hand
>> few people asked me to provide more granular packages for qt5, so
>> instead of disabling debian rename everywhere why don't we split the
>> packages with multiple libs or define LEAD_SONAME where one library is
>> significantly more important than the rest and the package should be
>> named after it?
>
> I have mixed feelings about this. I do see the value of splitting it
> more and I also see why people may want it in less fragmented set of
> runtime packages.
>
> Putting a second thought on this I think I agree with you. The
> benefits of splitting it more are higher than having less runtime
> packages.
>
> I think we could take a look at the package split done in Debian for
> inspiration and this would help to reduce many iterations to get this
> right. What do you think?
>

I think the package split is something we should do, and has been on my 
want-to-do list. This patch was an attempt to get packages in consistent 
order until such time that the debian naming works correctly for all 
modules. I haven't looked how Debian splits the packages, but that 
sounds good place to start.



More information about the Openembedded-devel mailing list