All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] udisks situation
Date: Thu, 13 Feb 2020 10:43:00 +0100	[thread overview]
Message-ID: <140df557-3b15-3f36-ac78-9d8d3139ad63@mind.be> (raw)
In-Reply-To: <4669dcc6-5080-22fc-702e-74f145a1a936@benettiengineering.com>



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

  parent reply	other threads:[~2020-02-13  9:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 20:52 [Buildroot] udisks situation Giulio Benetti
2020-02-12 21:34 ` Peter Korsgaard
2020-02-12 21:44   ` Giulio Benetti
2020-02-12 22:23     ` Peter Korsgaard
2020-02-13  9:43 ` Arnout Vandecappelle [this message]
2020-02-13 14:59   ` Adam Duskett
2020-02-13 16:19   ` Giulio Benetti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=140df557-3b15-3f36-ac78-9d8d3139ad63@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.