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

[Aaron Griffin]

On Thu, Sep 24, 2009 at 5:42 PM, Firmicus <Firmicus at gmx.net> wrote:
> 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 ;)

Yes, if anyone plans on doing prolonged changes to any of this, using
a remote git repo is the way to do it. No need to do pull requests for
1 patch every 3 months though :)