#923450 tech-ctte: requirements for being pre-dependency of bin:init

2019-03-20 Thread Margarita Manterola 
There was a bug filed to tech-ctte on Feb 28th that never reached our 
mailing list.


The email was rejected by Debian's list managing machine (bendel)
because Amavis said "bad header".  I'm copying it here now, so
that people that don't actively check our bug tracker also have
the context of this bug.

The bug is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923450


From: Dmitry Bogatov 
To: Debian Bug Tracking System 
Subject: tech-ctte: requirements for being pre-dependency of bin:init
Date: Thu, 28 Feb 2019 12:06:15 +

Package: tech-ctte
Severity: normal

Dear Technical Comitete,

  currently, inclusion of new init system into Debian requires inclusion 
into

pre-dependency of bin:init package, which is unsatisfactory.

As can be followed in #838480, current practice puts maintainer of any
new init system to be included into Debian at disadvantage, essentially
granting maintainer of bin:init (which happens to be `systemd' team now)
veto right. According to Constitution 3.1, individual developer poses
power of descision making only with regard their /own/ work.

Hereby, I ask TCCE to provide requirements init system must satisfy that
/warrants/ inclusion into pre-dependency of essential bin:init.
Alternatively, I ask to consider introducion of virtual package
'init-system'.

This summary of disagreement was proposed at least month ago, but there
were no input from other side (see #838480).
--
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction



--
Regards,
Marga

Next Meeting - Wednesday, March 20th 19:00 UTC (today)

2019-03-20 Thread Margarita Manterola 

Dear Technical Committee members,

Our monthly meeting will take place today at 19:00 UTC.

Our agenda for today is:

 * Review of previous meeting AIs
 * #904558 What should happen when maintscripts fail to restart a 
service

 * #923450 Requirements for being pre-dependency of bin:init
 * Additional Business

As we are around the change to summer time, remember that this meeting 
is in UTC.


For those of you in the US and Canada, this meeting will be an hour 
earlier than
the previous one.  For those of us in Europe and Mexico, this meeting is 
still at

the previous time and next meeting will be an hour earlier.

See you there!

--
Regards,
Marga

Bug#911225: marked as done (tech-ctte: Advice on stale libraries in a higher-precedence path entry)

2019-03-20 Thread Debian Bug Tracking System 
Your message dated Wed, 20 Mar 2019 09:34:35 +0100
with message-id <1cc9400c0f4f4a8feb29bcd41dc0f...@debian.org>
and subject line Re: Bug#911225: tech-ctte: Advice on stale libraries in a  
higher-precedence path entry
has caused the Debian Bug report #911225,
regarding tech-ctte: Advice on stale libraries in a higher-precedence path entry
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
911225: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911225
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

I would like advice from the technical committee on
. I am not asking for anyone to be
overruled.

GLib (src:glib2.0) consists of multiple libraries. The ones that are
relevant for this bug are libglib-2.0.so.0, which is low-level, and
libgobject-2.0.so.0, which is higher-level. They come from the same source
package (indeed, in Debian they are even in the same binary package)
and are expected/required/assumed to be upgraded in lockstep:
higher-level libraries from src:glib2.0 are allowed to assume that
the lower-level libraries are at exactly the same version.

In stretch and previous releases, libglib-2.0.so.0 was installed in
/lib/MULTIARCH, ostensibly for the benefit of early-boot services. It
isn't clear to me whether any early-boot services actually ever took
advantage of this.

In buster, libglib-2.0.so.0 was moved to /usr/lib/MULTIARCH, because
versions >= stretch only support a separate /usr if there is an initramfs
that mounts it before running the main system's init, and in particular
/usr/lib/MULTIARCH will be available by the time init starts. This removed
some apparently unnecessary complexity from the packaging, which had to
move the libraries around (we couldn't just set ${libdir} to
/lib/MULTIARCH, because higher-level parts of GLib needed to be in
/usr/lib/MULTIARCH anyway).

/lib/MULTIARCH appears in /etc/ld.so.conf.d with higher precedence than
/usr/lib/MULTIARCH.

In #896019 and #894763, it appears that some upgraded systems somehow
still contain a copy of libglib-2.0.so.0.4200.0 (corresponding to
GLib from jessie) in /lib/MULTIARCH. We don't know how this can have
happened. There are suggestions that it might have been caused by
filesystem corruption or installed by third-party software.

When it does, ldconfig sees that the obsolete library
has SONAME libglib-2.0.so.0, and creates a symlink
/lib/MULTIARCH/libglib-2.0.so.0. This takes precedence over the
newer version of libglib-2.0.so.0 that is correctly installed in
/usr/lib/MULTIARCH, resulting in the new libgobject-2.0.so.0 failing
to load, because it uses symbols that are only present in the new
libglib-2.0.so.0.

Possible resolutions include:

* Do nothing; consider the systems with a leftover
  /lib/MULTIARCH/libglib-2.0.so.0.4200.0 to be an unsupported local
  misconfiguration (this is the status quo)

* Move libglib-2.0.so.0 back to /lib/MULTIARCH permanently, at a
  long-term complexity cost

* Take steps to delete /lib/MULTIARCH/libglib-2.0.so.0.* during upgrade,
  taking care to avoid deleting files that are really on
  /usr/lib/MULTIARCH in merged-/usr systems, at a significant complexity
  cost, with some risk of deleting necessary files if we get it wrong

* Advocate merged /usr where this class of problem cannot happen :-)

Do technical committee members (other than me) have any thoughts on this?

Thanks,
smcv
--- End Message ---
--- Begin Message ---

The last time this was discussed was in our IRC meeting in November:
http://meetbot.debian.net/debian-ctte/2018/debian-ctte.2018-11-21-18.58.log.html

The advice provided by Didier was found sensible by several members of 
the Technical Committee.  Simon said that while he agreed it was 
sensible, it was more complex than expected.  Simon is free to implement 
whichever solution he finds both sensible and technically sound, but the 
committee has provided the advice requested.


Therefore, I'm here closing this bug as resolved.

--
Regards,
Marga--- End Message ---