Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1129389 > unrolled thread

Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec Neal Gompa <ngompa13@gmail.com> - 2022-12-19 13:10 +0100
    Bug#1026388: [Pkg-utopia-maintainers] Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec Michael Biebl <biebl@debian.org> - 2022-12-19 13:40 +0100
      Bug#1026388: [Pkg-utopia-maintainers] Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec Neal Gompa <ngompa13@gmail.com> - 2022-12-19 15:50 +0100
        Bug#1026388: [Pkg-utopia-maintainers] Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec Michael Biebl <biebl@debian.org> - 2022-12-19 18:00 +0100

#1129389 — Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec

Package: network-manager
Version: 1.40.6-1
Severity: wishlist

Dear Maintainer,

With the upcoming freeze of Debian Bookworm, I would like to request
that Debian's NetworkManager builds install their libexec binaries
in the upstream preferred location in /usr/libexec.

This aligns with what other distributions do today (notably Fedora
and openSUSE) and is permitted in Debian since policy standard 4.1.5.0
(released in 2018) because that is when FHS 3.0 (released in 2015) was
adopted by Debian.

I would prefer to see this fixed with Debian Bookworm to minimize the
continuing pain this deviation causes, especially for upstream projects
that rely on these binaries to activate parts of NetworkManager functionality.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.11-300.fc37.x86_64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages network-manager depends on:
ii  adduser                         3.129
ii  dbus [default-dbus-system-bus]  1.14.4-1
ii  libaudit1                       1:3.0.7-1.1+b2
ii  libbluetooth3                   5.66-1
ii  libc6                           2.36-6
ii  libcurl3-gnutls                 7.86.0-2
ii  libglib2.0-0                    2.74.2-1
ii  libgnutls30                     3.7.8-4
ii  libjansson4                     2.14-2
ii  libmm-glib0                     1.20.0-1
ii  libndp0                         1.8-1
ii  libnewt0.52                     0.52.23-1
ii  libnm0                          1.40.6-1
ii  libpsl5                         0.21.0-1.2
ii  libreadline8                    8.2-1.2
ii  libselinux1                     3.4-1+b3
ii  libsystemd0                     252.2-2
ii  libteamdctl0                    1.31-1
ii  libudev1                        252.2-2
ii  polkitd                         122-1
ii  udev                            252.2-2

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.88-1
ii  libpam-systemd               252.2-2
ii  modemmanager                 1.20.0-1
ii  ppp                          2.4.9-1+1.1+b1
ii  wireless-regdb               2022.06.06-1
ii  wpasupplicant                2:2.10-9+b2

Versions of packages network-manager suggests:
pn  iptables       <none>
pn  libteam-utils  <none>

Versions of packages network-manager is related to:
pn  isc-dhcp-client  <none>

-- no debconf information

[toc] | [next] | [standalone]

#1129393 — Bug#1026388: [Pkg-utopia-maintainers] Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec

[Multipart message — attachments visible in raw view] — view raw

Hi Neal

Am 19.12.22 um 13:04 schrieb Neal Gompa:
> Package: network-manager
> Version: 1.40.6-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> With the upcoming freeze of Debian Bookworm, I would like to request
> that Debian's NetworkManager builds install their libexec binaries
> in the upstream preferred location in /usr/libexec.
> 
> This aligns with what other distributions do today (notably Fedora
> and openSUSE) and is permitted in Debian since policy standard 4.1.5.0
> (released in 2018) because that is when FHS 3.0 (released in 2015) was
> adopted by Debian.
> 
> I would prefer to see this fixed with Debian Bookworm to minimize the
> continuing pain this deviation causes, especially for upstream projects
> that rely on these binaries to activate parts of NetworkManager functionality.

As the freeze is already pretty close and this potentially affects all 
the following packages, I'd like to postpone this transition to 
bookworm+1 to avoid unnecessary churn this close to the freeze and 
ending up with a half-done transition:

Packages installing VPN service files:
> $ apt-file search /usr/lib/NetworkManager/VPN/
> network-manager-fortisslvpn: /usr/lib/NetworkManager/VPN/nm-fortisslvpn-service.name
> network-manager-iodine: /usr/lib/NetworkManager/VPN/nm-iodine-service.name
> network-manager-l2tp: /usr/lib/NetworkManager/VPN/nm-l2tp-service.name
> network-manager-openconnect: /usr/lib/NetworkManager/VPN/nm-openconnect-service.name
> network-manager-openvpn: /usr/lib/NetworkManager/VPN/nm-openvpn-service.name
> network-manager-pptp: /usr/lib/NetworkManager/VPN/nm-pptp-service.name
> network-manager-ssh: /usr/lib/NetworkManager/VPN/nm-ssh-service.name
> network-manager-sstp: /usr/lib/NetworkManager/VPN/nm-sstp-service.name
> network-manager-strongswan: /usr/lib/NetworkManager/VPN/nm-strongswan-service.name
> network-manager-vpnc: /usr/lib/NetworkManager/VPN/nm-vpnc-service.name

At least network-manager-iodine would currently be broken by this 
change, as it doesn't hard-code the full-path to the auth-dialog, see 
[1]. Then there is of course NetworkManager itself, 
network-manager-gnome (nm-connection-editor/nm-applet) which currently 
use --libexecdir=/usr/lib/NetworkManager.

I think, once network-manager-iodine is fixed, NM can start using 
/usr/libexec and packages can migrate to the new path at their own pace.
Once bookworm+1 is open for development, I would file corresponding 
wishlist bugs against the packages above.

Hope that makes sense.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026385

[toc] | [prev] | [next] | [standalone]

#1129409 — Bug#1026388: [Pkg-utopia-maintainers] Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec

On Mon, Dec 19, 2022 at 7:28 AM Michael Biebl <biebl@debian.org> wrote:
>
> Hi Neal
>
> Am 19.12.22 um 13:04 schrieb Neal Gompa:
> > Package: network-manager
> > Version: 1.40.6-1
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > With the upcoming freeze of Debian Bookworm, I would like to request
> > that Debian's NetworkManager builds install their libexec binaries
> > in the upstream preferred location in /usr/libexec.
> >
> > This aligns with what other distributions do today (notably Fedora
> > and openSUSE) and is permitted in Debian since policy standard 4.1.5.0
> > (released in 2018) because that is when FHS 3.0 (released in 2015) was
> > adopted by Debian.
> >
> > I would prefer to see this fixed with Debian Bookworm to minimize the
> > continuing pain this deviation causes, especially for upstream projects
> > that rely on these binaries to activate parts of NetworkManager functionality.
>
> As the freeze is already pretty close and this potentially affects all
> the following packages, I'd like to postpone this transition to
> bookworm+1 to avoid unnecessary churn this close to the freeze and
> ending up with a half-done transition:
>
> Packages installing VPN service files:
> > $ apt-file search /usr/lib/NetworkManager/VPN/
> > network-manager-fortisslvpn: /usr/lib/NetworkManager/VPN/nm-fortisslvpn-service.name
> > network-manager-iodine: /usr/lib/NetworkManager/VPN/nm-iodine-service.name
> > network-manager-l2tp: /usr/lib/NetworkManager/VPN/nm-l2tp-service.name
> > network-manager-openconnect: /usr/lib/NetworkManager/VPN/nm-openconnect-service.name
> > network-manager-openvpn: /usr/lib/NetworkManager/VPN/nm-openvpn-service.name
> > network-manager-pptp: /usr/lib/NetworkManager/VPN/nm-pptp-service.name
> > network-manager-ssh: /usr/lib/NetworkManager/VPN/nm-ssh-service.name
> > network-manager-sstp: /usr/lib/NetworkManager/VPN/nm-sstp-service.name
> > network-manager-strongswan: /usr/lib/NetworkManager/VPN/nm-strongswan-service.name
> > network-manager-vpnc: /usr/lib/NetworkManager/VPN/nm-vpnc-service.name
>
> At least network-manager-iodine would currently be broken by this
> change, as it doesn't hard-code the full-path to the auth-dialog, see
> [1]. Then there is of course NetworkManager itself,
> network-manager-gnome (nm-connection-editor/nm-applet) which currently
> use --libexecdir=/usr/lib/NetworkManager.
>
> I think, once network-manager-iodine is fixed, NM can start using
> /usr/libexec and packages can migrate to the new path at their own pace.
> Once bookworm+1 is open for development, I would file corresponding
> wishlist bugs against the packages above.
>
> Hope that makes sense.

It does, though if all these packages are group-maintained by Utopia,
wouldn't it be possible to do the path migration for Bookworm through
NMUs?


-- 
真実はいつも一つ！/ Always, there's only one truth!

[toc] | [prev] | [next] | [standalone]

#1129441 — Bug#1026388: [Pkg-utopia-maintainers] Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec

[Multipart message — attachments visible in raw view] — view raw

Am 19.12.22 um 15:44 schrieb Neal Gompa:

> It does, though if all these packages are group-maintained by Utopia,
> wouldn't it be possible to do the path migration for Bookworm through
> NMUs?

They aren't unfortunately. Only three of the above 10 VPN plugins are 
maintained within the utopia. Otherwise I agree it would have been 
rather easy.

Regards,
Michael

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web