Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Sean Whitton]

Hello Guillem,

On Wed 14 Jul 2021 at 11:40PM +02, Guillem Jover wrote:

> On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
>> Sean Whitton dixit:
>> >* #978636 move to merged-usr-only?
>> >
>> >  We were asked to decide whether or not Debian 'bookworm' should
>> >  continue to support systems which are not using the merged-usr
>> >  filesystem layout.  We decided that support should not continue beyond
>> >  Debian 'bullseye'.
>>
>> What? WHAT? ＷＨＡＴ？
>>
>> >  The decision is captured here:
>> >  
>>
>> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
>> Debian is becoming untenable. Years ago, I had hoped it won’t.
>
> I've been meaning to send a note about this for some time now, but
> as I feel it keeps getting ignored, it always seems a bit pointless.
>
> But in any case, given that merged-usr-via-aliased-dirs is not really
> supported by dpkg anyway, it is broken by design [B], I have no
> intention whatsoever to break any of my systems with such layout going
> forward, I'm thus planning to spend any necessary volunteer time
> implementing any fix, workaround or solution required to avoid having
> to use it, in detriment of other Debian volunteer time. I already
> started some time ago with dpkg-fsys-usrunmess(8), present already in
> the upcoming bullseye release.
>
> [B] 
> 

Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
what I would get if I typed 'debootstrap bullseye /foo', right?

I would like to note that the TC decision did not specify any particular
implementation of merged-/usr.  It was just about whether to continue to
try to support both.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Jonathan Carter]

Hi Sean

On 2021/07/15 09:04, Sean Whitton wrote:
> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
> what I would get if I typed 'debootstrap bullseye /foo', right?
> 
> I would like to note that the TC decision did not specify any particular
> implementation of merged-/usr.  It was just about whether to continue to
> try to support both.

I think a more detailed explanation/expansion/clarification on what
exactly this means (and ideally also the rationale behind) that in the
bug report would be appreciated.

thanks,

-Jonathan

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marc Haber]

On Thu, 15 Jul 2021 09:56:18 +0200, Jonathan Carter 
wrote:
>On 2021/07/15 09:04, Sean Whitton wrote:
>> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
>> what I would get if I typed 'debootstrap bullseye /foo', right?
>> 
>> I would like to note that the TC decision did not specify any particular
>> implementation of merged-/usr.  It was just about whether to continue to
>> try to support both.
>
>I think a more detailed explanation/expansion/clarification on what
>exactly this means (and ideally also the rationale behind) that in the
>bug report would be appreciated.

Can we please delay this discussion until after the release? I don't
think we can afford an additional time sink at the moment. Please, get
bullseye out of the door first, then decide how many existing users
we're going to drive away from Debian in the next round.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Luca Boccassi]

On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > Sean Whitton dixit:
> > > * #978636 move to merged-usr-only?
> > > 
> > >  We were asked to decide whether or not Debian 'bookworm' should
> > >  continue to support systems which are not using the merged-usr
> > >  filesystem layout.  We decided that support should not continue beyond
> > >  Debian 'bullseye'.
> > 
> > What? WHAT? ＷＨＡＴ？
> > 
> > >  The decision is captured here:
> > >  
> > 
> > No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> > Debian is becoming untenable. Years ago, I had hoped it won’t.
> 
> I've been meaning to send a note about this for some time now, but
> as I feel it keeps getting ignored, it always seems a bit pointless.
> 
> But in any case, given that merged-usr-via-aliased-dirs is not really
> supported by dpkg anyway, it is broken by design [B], I have no
> intention whatsoever to break any of my systems with such layout going
> forward, I'm thus planning to spend any necessary volunteer time
> implementing any fix, workaround or solution required to avoid having
> to use it, in detriment of other Debian volunteer time. I already
> started some time ago with dpkg-fsys-usrunmess(8), present already in
> the upcoming bullseye release.
> 
> [B] 
> 
> 
> Thanks,
> Guillem

Hi,

As it has been said and written many times already, in reality this is
not broken by design at all and in fact it is the only successful
strategy that has been deployed by other distros - it's what is being
called merged-usr-via-moves-and-symlink-farms that is broken. We can
say this with certainty because both approaches have been tried, so
there's actual real-world data to look at. Just go look at the absolute
mess that Suse got themselves into by following that solution - a 10-
years-long massive half-done-never-finished headache that took an
inordinate amount of work to back out of, and move to the actual
working solution that everybody else are using - merged-usr-via-
aliased-dirs. On the other hand Fedora/RHEL had a smooth and simple
transition using merged-usr-via-aliased-dirs, and that was the end of
it.

Dpkg has some very minor bugs that rpm/dnf/yum/zypper/whatever do not
suffer from. So what? It is perfectly normal as it's software and all
softwares have bugs. They could be fixed, worked around, or ignored,
like all other bugs.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Jonathan Carter]

On 2021/07/15 10:47, Marc Haber wrote:
> Can we please delay this discussion until after the release?

To be clear, I was requesting further details from the TC, not a
re-evaluation or further discussion.

-Jonathan

Bug#991137: ITP: slurm-tools -- tools for the slurm HPC workload manager

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: slurm-tools
  Version : 0+git20210715
  Upstream Authors: Ole Holm Nielsen
* URL : https://github.com/OleHolmNielsen/Slurm_tools
* License : GPL-3-or-later
  Description : tools for the slurm HPC workload manager
 This is a collection of these tools:
  - pestat Print Slurm nodes status with 1 line per node including job 
info.

  - more tools to manage accounting, user jobs and more.

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Sean Whitton]

Hello,

On Thu 15 Jul 2021 at 09:56AM +02, Jonathan Carter wrote:

> Hi Sean
>
> On 2021/07/15 09:04, Sean Whitton wrote:
>> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
>> what I would get if I typed 'debootstrap bullseye /foo', right?
>>
>> I would like to note that the TC decision did not specify any particular
>> implementation of merged-/usr.  It was just about whether to continue to
>> try to support both.
>
> I think a more detailed explanation/expansion/clarification on what
> exactly this means (and ideally also the rationale behind) that in the
> bug report would be appreciated.

You're right, it would have been good if our Bits mail had linked to
some other messages in that thread rather than just the statement of the
result of the vote.  I'm sorry we didn't spot that before sending it.

Additionally, as someone else was kind enough to point out to me
off-list, my statement that "the TC decision did not specify any
particular implementation of merged-/usr" was rather misleading.  What I
should have written was that we did not specify any particular
implementation of the *migration* to merged-/usr for existing systems.

ISTM that "merged-usr-via-aliased-dirs" could refer to the migration
path implemented by the usrmerge package, and/or simply the replacement
of the directories /lib, /bin etc. with symlinks.  To the extent that it
refers to the latter, the TC decision does indeed specify that we will
implement merged-/usr using merged-usr-via-aliased-dirs.

Here are some useful messages we should have linked to:




and of course


-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#991148: ITP: icinga-php-library -- Icinga PHP Library for Icinga Web 2

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
pkg-nagios-de...@lists.alioth.debian.org

* Package name: icinga-php-library
  Version : 0.6.0
  Upstream Author : Icinga GmbH
* URL : https://icinga.com
* License : MIT
  Programming Lang: PHP
  Description : Icinga PHP Library for Icinga Web 2

 Icinga Web 2 is a very modular, fast and simple web interface for your Icinga
 monitoring environment.
 .
 The software will give you a web frontend for your monitoring solution, and
 can run additional modules, extending monitoring data, or even supplying
 something new to the webinterface.
 .
 This package provides the Icinga PHP libraries.

The package is required for icingaweb2 (>= 2.9.0) and will be maintained within 
the Nagios team.

Bug#991149: ITP: icinga-php-thirdparty -- Icinga PHP Thirdparty libraries for Icinga Web 2

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
pkg-nagios-de...@lists.alioth.debian.org

* Package name: icinga-php-thirdparty
  Version : 0.10.0
  Upstream Author : Icinga GmbH
* URL : https://icinga.com
* License : MIT
  Programming Lang: PHP
  Description : Icinga PHP Thirdparty libraries for Icinga Web 2

 Icinga Web 2 is a very modular, fast and simple web interface for your Icinga
 monitoring environment.
 .
 The software will give you a web frontend for your monitoring solution, and
 can run additional modules, extending monitoring data, or even supplying
 something new to the webinterface.
 .
 This package provides the Icinga PHP thirdparty libraries.

The package is required for icingaweb2 (>= 2.9.0) and will be maintained within 
the Nagios team.

Work-needing packages report for Jul 16, 2021

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1225 (new: 4)
Total number of packages offered up for adoption: 203 (new: 0)
Total number of packages requested help for: 61 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   bglibs (#991029), orphaned 2 days ago
 Description: BG Libraries Collection
 Reverse Depends: bcron cvm cvm-mysql cvm-pgsql libbg-dev mailfront
   twoftpd ucspi-proxy
 Installations reported by Popcon: 46
 Bug Report URL: https://bugs.debian.org/991029

   easyh10 (#991083), orphaned 2 days ago
 Description: Utility to manage the iRiver H10 music player
 Installations reported by Popcon: 2
 Bug Report URL: https://bugs.debian.org/991083

   gdbm (#991028), orphaned 2 days ago
 Description: GNU dbm database routines
 Reverse Depends: avahi-utils clisp-module-gdbm courier-authlib
   courier-authlib-userdb courier-base courier-imap courier-mlm
   courier-mta couriergrey elk (47 more omitted)
 Installations reported by Popcon: 131097
 Bug Report URL: https://bugs.debian.org/991028

   mini-httpd-run (#991032), orphaned 2 days ago
 Description: Small HTTP server (Runit integration)
 Installations reported by Popcon: 3
 Bug Report URL: https://bugs.debian.org/991032

1221 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 203 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 1006 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc bfh-container-server
   courier-webadmin cvsweb debbugs-web doc-central (139 more omitted)
 Installations reported by Popcon: 92576
 Bug Report URL: https://bugs.debian.org/910917

   asciio (#968843), requested 327 days ago
 Description: dynamically create ASCII charts and graphs with GTK+2
 Installations reported by Popcon: 74
 Bug Report URL: https://bugs.debian.org/968843

   aufs (#963191), requested 390 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 11533
 Bug Report URL: https://bugs.debian.org/963191

   autopkgtest (#846328), requested 1688 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker sbuild-qemu
 Installations reported by Popcon: 1218
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3581 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 531
 Bug Report URL: https://bugs.debian.org/642906

   cargo (#860116), requested 1556 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 2296
 Bug Report URL: https://bugs.debian.org/860116

   courier (#978755), requested 196 days ago
 Description: Courier mail server
 Reverse Depends: courier-faxmail courier-filter-perl courier-imap
   courier-ldap courier-mlm courier-mta courier-pcp courier-pop
   courier-webadmin couriergrey (3 more omitted)
 Installations reported by Popcon: 977
 Bug Report URL: https://bugs.debian.org/978755

   cron (#984736), requested 130 days ago
 Description: new maintainer need
 Reverse Depends: apticron autolog backintime-common btrfsmaintenance
   buildd checksecurity clamtk cricket email-reminder exim4-base (20
   more omitted)
 Installations reported by Popcon: 198134
 Bug Report URL: https://bugs.debian.org/984736

   cyrus-imapd (#921717), requested 888 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 421
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 2122 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav
   cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd
   cyrus-murder (78 more omitted)
 Installations reported by Popcon: 197608
 Bug Report URL: https://bugs.debian.org/799864

   dbad (#94755

Re: merged /usr considered harmful

[Thorsten Glaser]

Marc Haber dixit:

>think we can afford an additional time sink at the moment. Please, get

While that’s true…

>Can we please delay this discussion until after the release? I don't

… we can’t afford to: the TC discussion becomes valid as soon as
bullseye is released, which is in two weeks, and the people who
want to make Debian into a Fedora/RedHat/systemd-OS derivative
are going to rely on it and make our lives harder immediately.
They have proven time and time again, cf. #921012, #964139, that
they’re interested in actively breaking nōn-systemd users’ cases,
even despite policy to the contrary (basically ignoring the latter
until they managed to change policy to their likes).

>bullseye out of the door first, then decide how many existing users
>we're going to drive away from Debian in the next round.

*sigh* and isn’t that true…

I *really* don’t get why…

ⓐ these things aren’t done in a derivative that’s *really* close
  to Debian proper but can do all the funky new stuff, preserving
  support for the old stuff in Debian itself, and…

ⓑ usrmerge is “needed” anyway; we were working rather well with the
  previous (and rather-recently-introduced) model of “either /usr
  must be on the same filesystem as / or you must use an initrd to
  mount it”.

Frankly, usrmerge is WORSE then what we had before, in all possible
ways. People are going to write unportable scripts and programs, for
example. Symlink farming and moving is also not going to cut it (also,
rules like “if ed(1) is installed, /bin/ed must be able to call it”
is where other distros failed during moving stuff to /usr).

Why is there such heavy incentive to break things that work, for any
price?

Disappointed, and having spent a day crossgrading and moving from
sid to bullseye,
//mirabilos
PS: Please keep me in Cc, I’m not subscribed here, too high-volume
PPS: This is really draining energy. I just refused adopting a package
 I use and which is rather useful because I just can’t any more.
 And there is flooding and… stuff.
-- 
22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man
damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch
nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich
wirklich verbreitet als erwachsenen literatur   ‣ who needs GUIs thus?

Bug#991159: ITP: golang-github-google-cel-go -- go library for evaluation of Common Expression Language

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-google-cel-go
  Version : 0.7.3-1
  Upstream Author : Google
* URL : https://github.com/google/cel-go
* License : Apache-2.0
  Programming Lang: Go
  Description : go library for evaluation of Common Expression Language
 The Common Expression Language (CEL) is a non-Turing complete language
 designed for simplicity, speed, safety, and portability.

This is a dependency of caddy caddy (#810890)