Re: Consul pending upload
On 13 September 2022 6:23:46 am IST, Shengjing Zhu <zhsj@debian.org> wrote:
>On Tue, Sep 13, 2022 at 8:48 AM Shengjing Zhu <zhsj@debian.org> wrote:
>>
>> Daniel Swarbrick <dswarbrick@debian.org> 于 2022年9月13日周二 08:26写道：
>>>
>>> On 12.09.22 22:41, Martina Ferrari wrote:
>>>
>>> > On 10/09/2022 16:13, Nilesh Patra wrote:
>>> >> src:nomad still B-D on consul, although you are right that it is out
>>> >> of testing, but
>>> >> IIRC it was in a good shape a while ago(but not now), even made it to
>>> >> last stable.
>>> >> So keeping consul _maybe_ useful (dunno for sure)
>>> >>
>>> >> Also, src:patroni package (still in testing) has a "test-dep" in
>>> >> d/tests/control on
>>> >> consul, so that'd need to be dropped if you plan to remove it.
>>> >
>>> > Honestly, I don't have much time or motivation to work on consul.
>>> > Unless somebody with an interest on it steps up and works on closing
>>> > the RC bugs, it will end being removed from testing very soon..
>>>
>>> Following the trail of broken builds back to the origin, it seems that
>>> it all steps from not being able to build boltdb on riscv64. Upstream,
>>> boltdb was forked (now lives at https://github.com/etcd-io/bbolt), and
>>> this would involve package renaming and import path changes.
>>>
>>> However, looking at the changelogs for bbolt, I suspect that we could
>>> make the existing boltdb package support riscv64 simply by
>>> cherry-picking this as a patch for now:
>>> https://github.com/etcd-io/bbolt/pull/159/files
>>>
>>> That should then unblock bug #1004303 and ultimately allow consul to
>>> build on riscv64 (bug #1010306).
>>
>>
>>
>> Why you think this thread is about the FTBFS on riscv64? It won't render consul rc-buggy.
>>
>> Consul is to be removed because no one takes time to maintain it and it has open security bug for a long time.
>
>
>Another option is to only keep the consul api package, which is used
>by prometheus/etc.
>
>We have the general problem that when we only want a subset package of
>a library, we end up maintaining a monster package.
In such a case maybe it's better to embed parts of libraries using vendor/ dir instead of maintaining a monster package, and caring for it when it might not be of much use.
Or to actively purge parts of monster package that's not related (for instance stripping of the arch:any binary package and providing the lib part of it if that's needed)
--
Best,
Nilesh
Reply to: