Bug#856060: Please don't use obsolete libsysfs-dev any more

2021-08-10 Thread Guillem Jover
Hi!

On Sun, 2017-04-09 at 10:17:41 +0200, Philipp Kern wrote:
> On 02/24/2017 11:05 PM, Michael Biebl wrote:
> > Some years ago libsysfs (source package: sysfsutils) was written as an
> > abstraction layer for accessing /sys/. However, this turned out to be
> > a historical error and evolutionary dead end: It does not actually
> > abstract anything (it's just as specific to the Linux kernel and a
> > particular version thereof as /sys itself), and just adds unnecessary
> > complexity, RAM overhead, and bugs. Thus its development has ceased
> > years ago, in favor of programs just using /sys as it is.

Upstream development for sysfsutils is still going, they have f.ex.
merged all patches Debian was carrying, plus several cleanup patch
series I've sent, and have done new upstream releases. As the current
maintainer in Debian I do not consider it obsolete, and would
encourage anyone to use it, in preference of having to manually parse
stuff from /sys.

> > In fact, most applications probably don't want to access /sys at all,
> > but use libudev [1] or gudev [2] instead. These provide a better API
> > for device enumeration, properties, and callbacks for hardware
> > changes.
> 
> I can see how we ended up here, but it still does abstract something
> away: access to sysfs, avoiding bugs in accessing it from C in the process.

Indeed.

So from my side, if you'd like to switch to something else, for
whatever reason, that's fine, but if you'd rather keep using libsysfs,
then that should also be fine.

Thanks,
Guillem



Bug#856060: Please don't use obsolete libsysfs-dev any more

2017-04-09 Thread Philipp Kern
Hi Michael,

On 02/24/2017 11:05 PM, Michael Biebl wrote:
> Some years ago libsysfs (source package: sysfsutils) was written as an
> abstraction layer for accessing /sys/. However, this turned out to be
> a historical error and evolutionary dead end: It does not actually
> abstract anything (it's just as specific to the Linux kernel and a
> particular version thereof as /sys itself), and just adds unnecessary
> complexity, RAM overhead, and bugs. Thus its development has ceased
> years ago, in favor of programs just using /sys as it is.
> 
> In fact, most applications probably don't want to access /sys at all,
> but use libudev [1] or gudev [2] instead. These provide a better API
> for device enumeration, properties, and callbacks for hardware
> changes.

I can see how we ended up here, but it still does abstract something
away: access to sysfs, avoiding bugs in accessing it from C in the process.

Both this and s390-netdevice use libsysfs to iterate over devices on
a specified bus, extracting and writing some attributes (stuff like
"online" (r/w), "devtype" (r/o), "cutype" (r/o), setting the ccwgroup,
layer2 and portno settings on Ethernet adapters). Is that something
libudev would be suitable for? If so, it'd need to grow a udeb.

Interestingly enough glib does have a udeb. Would that mean that gudev
could be a potential option? Would that just require a udeb for udev and
one for gudev (which has 40k on my system)? That might be more pleasant
to work with.

> This package is one of the few which still use the old libsysfs. Can
> you please check with upstream to prepare a migration away from
> libsysfs to using plain /sys or libudev? I hope that we can drop the
> old libsysfs entirely for wheezy.

Unfortunately for this and s390-netdevice there's no upstream to work with.

> Thank you for considering!
> 
> 
> [1] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/

This link is broken.

> [2] http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/

And so is this one.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature


Bug#856060: Please don't use obsolete libsysfs-dev any more

2017-02-24 Thread Michael Biebl
Source: s390-dasd
Version: 0.0.47
Severity: important
User: mp...@debian.org
Usertags: libsysfs-deprecation

Hello,

Some years ago libsysfs (source package: sysfsutils) was written as an
abstraction layer for accessing /sys/. However, this turned out to be
a historical error and evolutionary dead end: It does not actually
abstract anything (it's just as specific to the Linux kernel and a
particular version thereof as /sys itself), and just adds unnecessary
complexity, RAM overhead, and bugs. Thus its development has ceased
years ago, in favor of programs just using /sys as it is.

In fact, most applications probably don't want to access /sys at all,
but use libudev [1] or gudev [2] instead. These provide a better API
for device enumeration, properties, and callbacks for hardware
changes.

This package is one of the few which still use the old libsysfs. Can
you please check with upstream to prepare a migration away from
libsysfs to using plain /sys or libudev? I hope that we can drop the
old libsysfs entirely for wheezy.

Thank you for considering!


[1] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/
[2] http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)