[arch-general] Independent arch field in sub packages? (Was: Re: [commitpkg] Some stylistic cleanup)

[Firmicus]

Evangelos Foutras a écrit :
> Eric Bélanger wrote:
>> On Wed, Sep 23, 2009 at 3:53 PM, Evangelos Foutras
>> <foutrelis at gmail.com> wrote:
>>  
>>> Aaron Griffin wrote:
>>>    
>>>> On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras
>>>> <foutrelis at gmail.com>
>>>> wrote:
>>>> I pushed all of your patches. The last one didn't apply cleanly, so I
>>>> had to do some tweaking. It was most likely related to me removing
>>>> trailing whitespace from the svn spacing commit.
>>>>
>>>> Thanks a lot!
>>>>       
>>> Thanks for applying the patches to devtools.
>>>
>>> I have a question. Currently, sub packages can't have a different
>>> architecture field than the main package. Are there plans to add this
>>> possibility in the future? This could come in handy with packages
>>> that have
>>> huge data files that are architecture independent and can be split
>>> into a
>>> sub package with arch=('any').
>>>
>>> I'm mainly asking because if the above gets implemented, commitpkg
>>> will need
>>> to be slightly modified in order to be able to locate -any sub
>>> packages (and
>>> I have a feeling that it was able to do this before my patches were
>>> applied
>>> :d ).
>>>
>>>     
>>
>> There's already a feature request in flyspray:
>> http://bugs.archlinux.org/task/15955
>
> I see. So there will be in total three variables that can be
> overridden in a sub package that affect its final filename; pkgver,
> pkgrel, and arch. Finding those variables before defining pkgfile as
> "${_pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" should allow
> commitpkg to cope with these sub packages.
>
> Hmmm, this definitely needs some more thinking. :)
>

Funny, I was thinking of all these things yesterday too...

I have also restructured commitpkg and co. quite a bit, and wanted to
send a bunch of 8 patches, but Evangelos was faster :) Now I cannot
easily rebase my branch, if at all :) Well, I now think I'll rather
setup my own git repo for devtools instead, and I'll send pull requests
to Aaron from time to time. That's more convenient than flooding the ML
with patches.

I have some ideas for refactoring devtools. I'll wikify them soon and
will report back ;)

F