[Buildroot] udisks situation

Adam Duskett aduskett at gmail.com
Thu Feb 13 14:59:54 UTC 2020


To be fair, I use udisks in my projects. It's quite handy for handling sdcards!


On Thu, Feb 13, 2020 at 1:43 AM Arnout Vandecappelle <arnout at mind.be> 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.
>
>  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!
>
>  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


More information about the buildroot mailing list