[Buildroot] udisks situation

[Giulio Benetti]

Hi Arnout,

On 2/13/20 10:43 AM, Arnout Vandecappelle wrote:
> 
> 
> On 12/02/2020 21:52, Giulio Benetti wrote:
>> Hi All,
>>
>> during bump of udisks package from version 1.0.5(the last known 1.x version) to
>> version 2.8.4 lot of heavy dependencies have been added:
>> - gobject-introspection(upcoming from Adam Duskett[1])
>> - libblockdev(upcoming from me) => libbytesize, volume_key(upcoming from me)
>> - parted
>> - polkit
>> - sg3-utils
>> - libxslt
>> then it needs:
>> - toolchain w/ glibc
>> - nls enabled
>>
>> Adam Duskett, while testing(and fixing) my udisks branch[2] against its
>> gobject-introspection patchset[1], found out that currently Fedora provides both
>> udisks[3] and udisks2[4]. udisks(1) is considered obsolete but they still offer
>> it as a package.
>>
>> Upstream didn't create a dedicated 1.x branch, but considering the amount of
>> dependencies for version 2.x, maybe we could imitate Fedora and keep package
>> "udisks" as it is(since its development stopped on version 1.0.5), and package
>> "udisks2" that will follow upstream.
>>
>> The meaning to keep both packages is to have different memory footprints, but
>> most of all retro-fitting. udisks2 provides "udisksctrl" tool, while udisks(1)
>> provides "udisks" tool that are not compatible.
>>
>> I have already discussed about this in IRC with Thomas Petazzoni and we ended up
>> to keep udisks2 to follow upstream, but udisks(1) seems to be still used.
> 
>   What Fedora does is of little relevance to Buildroot IMO.
> 
>   Rather, let's look at who seems to be interested in the udisks package. Its
> last real change if from Pieterjan in 2016. The only real change before that is
> the addition of the package by Marek in 2013. So I'd say that probably nobody is
> using it.
> 
>   Our usual approach in such a case is to do whatever is the easiest. So in this
> case, I'd say: simply bump the udisks package even though it adds all those
> dependencies and the API changes.

Ok, then let's bump it following upstream.

>   If someone has a problem with that, we have several ways to fix it later, e.g.
> by adding a udisks1 package.
> 
> 
>> On the counterpart, being Buildroot an embedded linux build system, where the
>> system is not meant to be upgraded during its lifetime,
> 
>   Err, what? No no no, not upgrading during its lifetime would be a *very* bad idea!

Yes, you're right, indeed I'm looking at swupdate.

Thank you
-- 
Giulio Benetti
Benetti Engineering sas

>   Regards,
>   Arnout
> 
>> one could tell "do you
>> want udisks? So use new udisks and rewrite the interface to it on you
>> application or daemon.". But IMHO this case sounds to me similar(even if of
>> minor impact) to packages "gstreamer" and "gstreamer1".
>>
>> [1]: https://patchwork.ozlabs.org/project/buildroot/list/?series=157909
>> [2]: https://github.com/giuliobenetti/buildroot/tree/dev/udisks-bump
>> [3]: https://apps.fedoraproject.org/packages/udisks
>> [4]: https://apps.fedoraproject.org/packages/udisks2
>>
>> Best regards
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>