[Buildroot] udisks situation

[Buildroot] udisks situation

[Giulio Benetti]

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.

On the counterpart, being Buildroot an embedded linux build system, 
where the system is not meant to be upgraded during its lifetime, 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
-- 
Giulio Benetti
Benetti Engineering sas

[Buildroot] udisks situation

[Peter Korsgaard]

>>>>> "Giulio" == Giulio Benetti <giulio.benetti@benettiengineering.com> writes:

 > 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.

I don't feel strongly about either, but long term we have to follow
upstream.

Out of interest, why this focus on udisks? We don't have any packages
with reverse dependencies to udisks in Buildroot?

-- 
Bye, Peter Korsgaard

[Buildroot] udisks situation

[Giulio Benetti]

Hi Peter,

On 2/12/20 10:34 PM, Peter Korsgaard wrote:
>>>>>> "Giulio" == Giulio Benetti <giulio.benetti@benettiengineering.com> writes:
> 
>   > 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.
> 
> I don't feel strongly about either, but long term we have to follow
> upstream.
> 
> Out of interest, why this focus on udisks? We don't have any packages
> with reverse dependencies to udisks in Buildroot?

Everything started out when I've followed this:
https://elinux.org/Buildroot#Important
Following that I've already bumped at and nfs-utils is pending after 
upstreaming all patches.
I've update it during last 6 months, but only few days ago I've realized 
that it's not followed so much by chatting in IRC :-), this is the 
reason of udisks interest(it was listed there).
Basically I was trying to find something for Buildroot.

-- 
Giulio Benetti
Benetti Engineering sas

[Buildroot] udisks situation

[Peter Korsgaard]

>>>>> "Giulio" == Giulio Benetti <giulio.benetti@benettiengineering.com> writes:

Hi,

 >> Out of interest, why this focus on udisks? We don't have any packages
 >> with reverse dependencies to udisks in Buildroot?

 > Everything started out when I've followed this:
 > https://elinux.org/Buildroot#Important
 > Following that I've already bumped at and nfs-utils is pending after
 > upstreaming all patches.
 > I've update it during last 6 months, but only few days ago I've
 > realized that it's not followed so much by chatting in IRC :-), this
 > is the reason of udisks interest(it was listed there).
 > Basically I was trying to find something for Buildroot.

Ahh ok ;)

-- 
Bye, Peter Korsgaard

[Buildroot] udisks situation

[Arnout Vandecappelle]

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

[Buildroot] udisks situation

[Adam Duskett]

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@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

[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
>