Re: support for merged /usr in Debian

[Thorsten Glaser]

Marco d'Itri  Linux.IT> writes:

> grml-rescueboot is way more useful for rescue purposes.

It is… except, I didn’t take it into account when creating the 256 MiB /boot
for a laptop, and the regular kernel and initrd are huge already these days,
and then you have two of them, plus a temporary initrd while it is being
updated, and boom, no space left for Grml ☹

And everything else is under crypt + LVM + whatnot, so extending that is
very hard.

I generally partition /+swap-only (plus special needs filesystems, such
as /boot, or /var/anoncvs for a system which also runs a mirror, to keep
it separate), but I’d much prefer to not have to do change for the sake
of change, so I request this change be optional.

Thanks,
//mirabilos

Re: support for merged /usr in Debian

[Thorsten Glaser]

Ansgar Burchardt  debian.org> writes:

> Marc Haber  writes:

> > I, for example, am afraid of having to merge /usr in existing systems
> > during upgrades, causing repartitions to be necessary. I am afraid of
> > partition layout suddenly not fitting any more during an upgrade,
> > causing downtimes and customers considering to take the opportunity to
> > migrate to a really supported enterprise distribution.
> 
> Are you afraid of your /usr partition being too small to hold the
> additional binaries from /bin, /sbin and /lib?  If that is the case,

Human mistakes also count.

And, consider:
http://article.gmane.org/gmane.linux.debian.devel.general/172133

bye,
//mirabilos

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 15:19:43 +0100, Tom H  wrote:
>Johann (I can't think of the other "fanboi" to whom you're referring)
>has argued in the past for the removal of rc.local and sysvinit
>compatibility.

People like him should be silenced on development mailing lists. They
don't care about the common sysadmin at all.

>Let's assume that Lennart removes support for them as
>well as for "EnvironmentFile=", will it really be something that'll be
>worth getting upset about?

It is worth getting upset when people try to "educate" me in a field
that doesn't need educating. It just triggers childhood aversions, and
I am surely not the only one.

>For EnvironmentFile, does it really matter whether you edit a file
>under "/etc/default/" or under "/etc/systemd/system/"?  As I said
>up-thread, I'm wouldn't like setting up nfs without "EnvironmentFile="
>but it's something that'll just take a little longer initially,
>whether I'm using config management or not. And then it'll be the
>same, since I only change these files at setup.

Being forced to change things as a systadmin just for the sake of
change is always bad. People not caring about backwards compatibility
do not care about their users. "Gut feeling" is an important
instrument in the seasoned sysadmin's life, and when the gut feeling
says "this should be a variable here" and you can't do it because the
darn system doesn't support variables, it leaves you with a bad
feeling. And I don't want to have bad feelings during my work. It's
not only my work, it's my passion. And it hurts to have it made worse
by people not caring about my passion.

This is the case for systemd, and, sadly, has become the case for
Debian in the last year or so.

>For rc.local, does it really matter whether you edit "/etc/rc.local"
>or a file under "/etc/systemd/system/"?

It matters if I have had rc.local on hundreds of systems for decades
and now need to change every one of them. I don't care so much how
configuration works in new installs (where I only need to change the
installation automatism), but if rc.local has been ticking away in
existing installs without the need for configuration management, this
change is unnecessary and means to have implementation and testing and
rollout and change management, which can easily amount to at least
half a work day even on a single big installation.

> Personally, even if I've used
>rc.local when in a hurry, I've always made a point of creating a
>sysvinit script, upstart job, or systemd service unit later.

Yes. rc.local is not something I care about. Removing the support for
/etc/default files just for the sake of educating people to do things
"right" and "in the correct systemd way" is outright evil.

>There's residual anger at systemd because it more or less snookered
>distros and users into adopting it,

... and now uses its leverage to force people into doing things their
way by slowly removing compatibility features. This is rearing its
ugly head, destroys trust and makes me feel that systemd should be
forked as soon as possible so that removed features can be patched in
again.

But I fear that systemd upsteam will promptly engage into "educating"
the people who dared to fork about that it is a bad idea to fork
systemd by starting needless refactoring in the code so that the
compatibility patches in the forked code don't apply as nicely, thus
causing lots of unnecessary work.

How did we allow these people to gain this much power over us?

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

Re: support for merged /usr in Debian

[Marc Haber]

[explanations snipped]

Thanks for trying to clarify. I'll stop ranting about that and revisit
things when we're in the freeze.

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

Re: support for merged /usr in Debian

[Neil Williams]

On Sun, 17 Jan 2016 09:07:56 +0100
Marc Haber  wrote:

> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl 
> wrote:
> >Amen. I'm much happier how the last couple of releases were handled.
> >The release team(s) did an outstanding job.
> >And things like autoremovals are a god send.  
> 
> I am not opposed to autoremovals. I am opposed to removing packages
> and not letting them back in after the bugs were fixed just because we
> can. We have never done this, and we shold not do that for stretch.

That is just an untruth, sorry.

At some point before the end of every freeze for every release, we have
*always* done this. It is inevitable. It may be (and preferably will
be) a short period at the very end of the freeze. It is stupid to allow
a package to migrate into what is to become stable the day before the
release - there must be *very* special reasons. Typically, the only
package that does that is debian-cd.

There *must* be a cut off, there has *always* been a cut-off. Whether
or not RC bugs are fixed, the package will not migrate unless the
release team decide that it should. Most of the way through the freeze
that is automatic. As it gets closer to the release, this stops
happening automatically. Anything else would mean we'd never actually
release at all. The lack of migration *into* the release at no point
precludes the need for the release team to remove a package from the
release, so there will always be a time at the end of the freeze where
removals cannot be undone, no matter the protests or complaints. At the
very end of the freeze, removals are no longer automatic but still
happen - after the point where return is possible. To be fair, the
release team don't take those decisions lightly but such removals have
happened for each of the releases with which I've been involved (back
to Lenny). None of the affected packages had any possibility of
returning into the release once removed and this was duly considered
as part of the removal. Sometimes, removal is simply the only way to
fix the bugs - the release can't wait forever or be held hostage to
buggy packages.

The reverse dependencies are considered too, it might be a fault in your
package but your package will still be removed from the release and
there will be situations where it will not be allowed to return.

This has been done for all releases, it will continue to be necessary
for stretch and subsequent releases. Automatic removal does not always
allow automatic return. Manual removal also does not always allow
return. Nothing guarantees that your package will be in the release,
diligence is required to keep up with email and bug reports, right up
until the last steps of the release.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpzTpNsrKaLV.pgp
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Tollef Fog Heen]

]] Marc Haber 

> We have never done this, and we shold not do that for stretch.

>From https://release.debian.org/jessie/freeze_policy.html:

After the 5th of February 2015, we will not allow packages to
re-enter testing if they are removed.

>From https://release.debian.org/wheezy/freeze_policy.html:

Rule #8. If your package has been removed recently (i.e. in the last
20 days) due to an RC bug, and you have an bugfix-only update
uploaded, you can contact the release team about letting your
package back in. Same as above: Do not expect us to find it out
ourselves. You need to push that.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 08:39:02 +, Neil Williams
 wrote:
>On Sun, 17 Jan 2016 09:07:56 +0100
>Marc Haber  wrote:
>
>> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl 
>> wrote:
>> >Amen. I'm much happier how the last couple of releases were handled.
>> >The release team(s) did an outstanding job.
>> >And things like autoremovals are a god send.  
>> 
>> I am not opposed to autoremovals. I am opposed to removing packages
>> and not letting them back in after the bugs were fixed just because we
>> can. We have never done this, and we shold not do that for stretch.
>
>That is just an untruth, sorry.
>
>At some point before the end of every freeze for every release, we have
>*always* done this. It is inevitable. It may be (and preferably will
>be) a short period at the very end of the freeze.

Of course. What I have understood is that this will be general freeze
policy from the beginning for stretch. I might have misunderstood in
the talk, and I didn't find a general freeze policy document to read
up on this yet.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 16 Jan 2016 20:24:34 +0100, Vincent Bernat 
wrote:
> ? 16 janvier 2016 17:37 +0100, Marc Haber  :
>
>>>You seem to always take vague examples to avoid being contradicted. You
>>>can execute any unit before and after network is setup through the
>>>dependency system.
>>
>> Show me how to set a certain option to a VLAN interface that is
>> created by /etc/systemd/network/foo.netdev and needs to be set before
>> the interface is taken "up" by /etc/systemd/network/foo.network. Both
>> unit files are processed by the same systemd-networkd.service with no
>> hook in between.
>
>#v+
>[Service]
>Type=oneshot
>ExecStart=/usr/bin/ip a l
>RemainAfterExit=yes
>
>[Install]
>WantedBy=multi-user.target
>
>[Unit]
>Description=Enable some unknown IPv6 feature now
>After=sys-subsystem-net-devices-vlan1.device
>Requires=sys-subsystem-net-devices-vlan1.device
>Before=sys-devices-virtual-net-vlan1.device
>Conflicts=sys-devices-virtual-net-vlan1.device
>#v-

Judging from man systemd.device, a .device file has something to do
with udev. A vlan device is not created by udev, it comes into
existence when a .netdev unit like 

|[1/501]mh@barrida:~$ cat /etc/systemd/network/int182.netdev 
|[NetDev]
|Name=int182
|Kind=vlan  
 
|   
 
|[VLAN] 
 
|Id=182 
 
|[2/502]mh@barrida:~$

is brought up. After the corresponding .network file:

|[2/502]mh@barrida:~$ cat /etc/systemd/network/int182.network
|[Match]
 
|Name=int182
 
|   
 
|[Network]  
 
|Description=int182 secure  
 
|DHCP=none  
 
|IPForward=yes  
 
|   
 
|[Address]  
 
|Address=192.168.182.254/24 
 
|   
 
|[Address]  
 
|Address=2a01:238:4071:3282::a3:100/64  
 
|
|[snip]
|
|[3/503]mh@barrida:~$ 

has been brought up, /proc/sys/net/ipv6/conf/int182/* options cannot
be set any more since the interface is already up. 

systemd upstrem acknowledged this issue by implementing, for example,
the IPv6AcceptRouterAdvertisements option. Unfortunately, because
systemd does not allow run-time extensions, one has to go this way
again and again and wait for a release of both systemd upstream and
the distribution when one needs other options such as the
accept_ra_from_local value.

>Of course, vlan1 is up because with networkd, configuring the "netdev" makes
>it up while in Debian, setting the IP makes it up. However, I don't see
>you whining about the lack of flexibility in Debian where you cannot
>execute a command when the interface is up but before it gets an IP.

Because ifupdown has pre-up and up options in /e/n/i and hooks for
scripts.

Btw, the word "whine" is offensive. Please cut that out.

>> People in the systemd community are asking us to not use
>> EnvironmentFile or otherwise Lennart might feel forced to remove it
>> since we're all using it wrong.
>>
>> This is what gets me absolutely furious.
>
>Already debunked here:
> https://lists.debian.org/debian-devel/2016/01/msg00384.html
>
>Also:
> https://lists.debian.org/debian-devel/2016/01/msg00075.html

Please note what prompted my outburst, and guess whose opinion gets
endorsed by systemd upstream.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 12:29:42 +0100, Vincent Bernat 
wrote:
> ? 17 janvier 2016 11:25 +0100, Marc Haber  :
>>>Of course, vlan1 is up because with networkd, configuring the "netdev" makes
>>>it up while in Debian, setting the IP makes it up. However, I don't see
>>>you whining about the lack of flexibility in Debian where you cannot
>>>execute a command when the interface is up but before it gets an IP.
>>
>> Because ifupdown has pre-up and up options in /e/n/i and hooks for
>> scripts.
>
>ifupdown doesn't give a hook for executing something after putting the
>interface up and before setting an IP address. This can be useful to
>check if we are plugged to the right switch port or to wait for the STP
>state of the remote switch to be "forwarding". That's a different kind
>of limitation.

Anyway, ifupdown used to be a lot more flexible than networkd is
today. networkd is still the better solution.

>networkd puts the interface up when creating it. It introduces an
>unfortunate limitation, just workaround it with an unit file. You'll
>have to accept at some point that upstream wants networkd to only cover
>the most common use cases and that for more complex setups, you have
>other solutions (like ifupdown, network manager or manual unit files).

networkd's feature set is celearly made for servers, otherwise it
would not support bonding, VLANs and bridging, hardly part of the
"most common use cases". IPv6 is much more common than bonding, for
example.

Networkd is just plagued by upstream's aversion against giving people
a choice and is hence missing an interface for local extensions. I
hate the idea of having to go through the same motions again and again
for every setting that the kernel people decided to expose. The kernel
community is so much easier to work with.

>> Btw, the word "whine" is offensive. Please cut that out.
>
>What's the proper english verb for someone who complains everytime in a
>negative way? Maybe "rant" would be more appropriate.

How about "complain"?

 People in the systemd community are asking us to not use
 EnvironmentFile or otherwise Lennart might feel forced to remove it
 since we're all using it wrong.

 This is what gets me absolutely furious.
>>>
>>>Already debunked here:
>>> https://lists.debian.org/debian-devel/2016/01/msg00384.html
>>>
>>>Also:
>>> https://lists.debian.org/debian-devel/2016/01/msg00075.html
>>
>> Please note what prompted my outburst, and guess whose opinion gets
>> endorsed by systemd upstream.
>
>I don't know what you mean. But I can understand that upstream prefers
>to endorse opinion of people who engage in constructive discussions
>instead of "ranting".

One can discuss constructiveness. The discussion was like:

Harald: "Please extend the EnvironmentFile syntax, I'd like to use it
in a slightly different way for my use case"
systemd upstream: "You're using it wrong. I should never have
implemented it."
systemd fanboi: "Let's remove it then!"
Harald: "No, I'm using it."
systemd fanboi: "You're using it wrong, systemd upstream said. Please
don't force systemd upstream to remove the feature by still continuing
to use it the wrong way! It's much better to fix your outdated daemon
to have its own configuration file instead of relying on command line
options since it's work for systemd to pass them! And, btw, your whole
way of doing system administration is wrong, please change it to the
only right way that we documented as being the only right way two
weeks ago!"
Zugschlus: ""

That's not what I call "constructive". It's talking about destroying
existing and working setups instead of caring for user wishes.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl 
wrote:
>Amen. I'm much happier how the last couple of releases were handled. The
>release team(s) did an outstanding job.
>And things like autoremovals are a god send.

I am not opposed to autoremovals. I am opposed to removing packages
and not letting them back in after the bugs were fixed just because we
can. We have never done this, and we shold not do that for stretch.

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

Re: support for merged /usr in Debian

[Neil Williams]

On Sun, 17 Jan 2016 10:21:15 +0100
Marc Haber  wrote:

> On Sun, 17 Jan 2016 08:39:02 +, Neil Williams
>  wrote:
> >On Sun, 17 Jan 2016 09:07:56 +0100
> >Marc Haber  wrote:
> >  
> >> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl
> >>  wrote:  
> >> >Amen. I'm much happier how the last couple of releases were
> >> >handled. The release team(s) did an outstanding job.
> >> >And things like autoremovals are a god send.
> >> 
> >> I am not opposed to autoremovals. I am opposed to removing packages
> >> and not letting them back in after the bugs were fixed just
> >> because we can. We have never done this, and we shold not do that
> >> for stretch.  
> >
> >That is just an untruth, sorry.
> >
> >At some point before the end of every freeze for every release, we
> >have *always* done this. It is inevitable. It may be (and preferably
> >will be) a short period at the very end of the freeze.  
> 
> Of course. What I have understood is that this will be general freeze
> policy from the beginning for stretch. I might have misunderstood in
> the talk, and I didn't find a general freeze policy document to read
> up on this yet.

Then the only reasonable basis is to use the past freeze policies, as
linked by Tollef, as the reference for the talk. I fail to see why
there is so much fuss over this, there will always be a time when
autoremovals are not let back in and that time has proven to be fairly
consistent in length over previous releases. It allows the release team
to sort out the more complex issues, it allows time for DI to finalise
and a raft of other essential tasks.

If the total freeze period is shortened, as so many people want, the
proportion of time taken up by this portion of the freeze process is
likely to increase. So, therefore, it is right to remind people that a
short freeze means that it is *more* likely that any one specific
package is going to be affected by a removal which cannot be undone. A
shorter timeframe for the release as a whole means that the ban on
packages returning, RC bug fixes or not, becomes more noticeable and
needs to be applied more overtly than before. The earlier that starts,
the shorter the release process can become (although there is an
element of diminishing returns as the release itself takes a finite
amount of time and the archive keeps getting larger).

Once upon a time, this removal process was manual and only done at the
"soft" start of the freeze but it still continued after the point where
returns were possible. We're permanently in that "soft" freeze by
using automated removals, so the real freeze (where removed
packages are unable to return) looks more severe. This "soft" freeze
then isn't part of the freeze policy for stretch, it's already in place.

The freeze itself becomes a period of time when automatic returns are
initially slowed (only packages already in the queue), then restricted
to RC fixes only (where most of the freeze time gets used up), then
banned. Manual migrations to return removed packages stop at some point
too. At another point, automated removals stop but manual removals
continue - possibly right up until the very final steps of the release.
Hence, removals (manual and automatic) will happen when there is no
prospect of return. All the talk was doing was highlighting that this
process will continue but will appear more prominently in a shorter
total freeze. It may also affect more packages as the archive continues
to grow. That is just mathematics, it is inevitable.

We still release "when it's ready" but due to the size of the archive,
there must be a threshold where the release team can decide that x
percent of the archive being ready is enough, so that the release is
not held hostage to particular packages. The value of x hasn't been 100
for a long time. Reality means that volunteers need to allocate time to
do the release tasks, so a date needs to be set when people are
available but the date isn't set until after the release team decide
that the threshold has been met.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp5_L3VAPKmf.pgp
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 11:25:50 +0100, Marc Haber
 wrote:
>Judging from man systemd.device, a .device file has something to do
>with udev. A vlan device is not created by udev, it comes into
>existence when a .netdev unit like 
>
>|[1/501]mh@barrida:~$ cat /etc/systemd/network/int182.netdev 
>|[NetDev]
>|Name=int182
>|Kind=vlan 
>  
>|  
>  
>|[VLAN]
>  
>|Id=182
>  
>|[2/502]mh@barrida:~$
>
>is brought up.

I forgot to give the eth0.network, which brings the connection between
VLAN device and physical device:

|[1/501]mh@barrida:~$ cat /etc/systemd/network/eth0.network 
|[Match]
 
|Name=eth0  
 
|   
 
|[Network]  
 
|VLAN=int181
 
|   
 
|[Network]  
 
|VLAN=int182
 
|   
 
|[Network]  
 
|VLAN=int183
 

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

Re: support for merged /usr in Debian

[Vincent Bernat]

 ❦ 17 janvier 2016 11:25 +0100, Marc Haber  :

>>Of course, vlan1 is up because with networkd, configuring the "netdev" makes
>>it up while in Debian, setting the IP makes it up. However, I don't see
>>you whining about the lack of flexibility in Debian where you cannot
>>execute a command when the interface is up but before it gets an IP.
>
> Because ifupdown has pre-up and up options in /e/n/i and hooks for
> scripts.

ifupdown doesn't give a hook for executing something after putting the
interface up and before setting an IP address. This can be useful to
check if we are plugged to the right switch port or to wait for the STP
state of the remote switch to be "forwarding". That's a different kind
of limitation.

networkd puts the interface up when creating it. It introduces an
unfortunate limitation, just workaround it with an unit file. You'll
have to accept at some point that upstream wants networkd to only cover
the most common use cases and that for more complex setups, you have
other solutions (like ifupdown, network manager or manual unit files).

> Btw, the word "whine" is offensive. Please cut that out.

What's the proper english verb for someone who complains everytime in a
negative way? Maybe "rant" would be more appropriate.

>>> People in the systemd community are asking us to not use
>>> EnvironmentFile or otherwise Lennart might feel forced to remove it
>>> since we're all using it wrong.
>>>
>>> This is what gets me absolutely furious.
>>
>>Already debunked here:
>> https://lists.debian.org/debian-devel/2016/01/msg00384.html
>>
>>Also:
>> https://lists.debian.org/debian-devel/2016/01/msg00075.html
>
> Please note what prompted my outburst, and guess whose opinion gets
> endorsed by systemd upstream.

I don't know what you mean. But I can understand that upstream prefers
to endorse opinion of people who engage in constructive discussions
instead of "ranting".
-- 
Familiarity breeds contempt -- and children.
-- Mark Twain


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Tom H]

On Sun, Jan 10, 2016 at 12:09 PM, Marc Haber
 wrote:
> On Sun, 10 Jan 2016 09:53:52 +0100, Tom H  wrote:
>>
>> Lennart didn't even say that he wanted to get rid of "EnvironmentFile=".
>>
>>> From the same-named thread on systemd-devel@:
>>
>> --- 8< ---
>> 1)
>> I probably should never have added EnvironmentFile= in the first place.
>>
>> 2)
>> I think EnvironmentFile= was a mistake, and I explained why. But then
>> again, I am not planning to remove it, and I never suggested that.
>> --- > 8 ---
>>
>> He advocated the use of drop-ins, as you (Philipp) do.
>
> Yes. But two of his militant fanbois suggested in the following that
> the option should be removed because of Lennarts reasoning. In the
> following, one of them said that if the option will be removed in the
> future, it would be "our" because "we" had been using the option
> "wrong" and have thus "forced lennart" to remove it since we refused
> to be "educated" about "proper" use of systemd.

Johann (I can't think of the other "fanboi" to whom you're referring)
has argued in the past for the removal of rc.local and sysvinit
compatibility. Let's assume that Lennart removes support for them as
well as for "EnvironmentFile=", will it really be something that'll be
worth getting upset about? I'm not trying to provoke you, I'm just
thinking it through.

For EnvironmentFile, does it really matter whether you edit a file
under "/etc/default/" or under "/etc/systemd/system/"? As I said
up-thread, I'm wouldn't like setting up nfs without "EnvironmentFile="
but it's something that'll just take a little longer initially,
whether I'm using config management or not. And then it'll be the
same, since I only change these files at setup.

For rc.local, does it really matter whether you edit "/etc/rc.local"
or a file under "/etc/systemd/system/"? Personally, even if I've used
rc.local when in a hurry, I've always made a point of creating a
sysvinit script, upstart job, or systemd service unit later. If the
rc.local support's removed, I might even create my own
"/etc/systemd/system/rc-local.service" to parse "/etc/rc.local" for
cases when I don't have the time to think through the dependencies of
a proper unit.

There's residual anger at systemd because it more or less snookered
distros and users into adopting it, but being angry at every little
change seems OTT, no matter how Lennart expresses his musts and
must-nots and his likes and dislikes.

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 11:12:37 +, Jonathan McDowell
 wrote:
>On Fri, Jan 08, 2016 at 07:09:59PM +0100, Marc Haber wrote:
>> On Fri, 8 Jan 2016 17:54:49 +, Jonathan McDowell
>>  wrote:
>> >You're not communicating clearly and this is indeed causing problems
>> >in this thread. You said "all my clients run unstable", not "all my
>> >client machines run unstable". You've also later said "I've not
>> >installed any new Debian systems at any client site". It is not
>> >unreasonable that the casual reader will assume you are using the
>> >term to mean a 3rd party who you are managing system for.
>> 
>> You're right to blame for only speaking english for 30 years of my
>> life and living in a country where TV programs are dubbed. I am also
>> deeply worried about the Operating System I still care about after 15
>> years and which works so hard to feel not like a home any more.
>
>I'm not sure how you've taken any of this meaning from my message. You
>have inconsistently used certain terms such that it's not surprising
>they have been misunderstood by others in this thread. I am not in any
>way complaining about your grasp of the English language.

And it happened again in the very next message. My bad. A client is a
computer, a customer is a company or an individual. In German, there
is a clear distinction between that since one also says "client" for
the computer and "Kunde" for the customer.

>> >As far as I can tell what he wants to happen is a) files in / and
>> >/usr locations not to conflict and b) policy to state that this
>> >should be the case.
>> 
>> If that is really the gist of those editorial changes[1], then this is
>> actually a misunderstanding. Maybe UsrMerge is even a misnomer.
>
>These are not editorial changes. There's a clear desire for a change in
>the way things are handled, and I don't believe there is any need to
>ascribe an ulterior motive to it. Marco wants to be able to merge / and
>/usr on his systems. Various other people do as well. If we, as a
>project, say that we should not have duplicate file names between these
>portions of the file system then they can have their desire and the rest
>of us can continue to keep them separate.

And I fear that the current motive will only be step one, with maybe
step three being the really harmful step. I'd like to stop an avalange
before it gets moving.

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

Re: support for merged /usr in Debian

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 04:09:00PM +0100, Marc Haber wrote:
> It would help to be friendly to each other. No CoC needed by that,
> it's just basic common sense.

The meaning of "friendly" and "common sense" is different for different people.
If you write down what you mean by that, it's called a CoC.  If you use it as a
guideline, and not a stick to beat with, it is exactly what you ask for.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmmHXAAoJEJzRfVgHwHE6E0cQAIKVkbk+jucSMCHj7fuhGRRb
VoS8lM0xDsMnh5pA3aVPtROXI8XTJOyGIRikr6g1q/vFJtEhDvkSIbJD9m2WfmXk
h2qXSAeXbR+xEZLPI3UlqL/8PvoNhczOQ09xKD5rqncL2KyRfSSWQQe53KN6l9MI
fMXwChpO8yzC29nn5KnMr8eSPjlhK+spOTZNj50YVZW6J6DkGvTQ8y8yHn0aDclp
iL8yKle1wKH981gJgMl3iUOWm/FLXUXQDknysapvXVN2T4R/rPiW+SVm080BKadh
Jy+JfTR0BKPfq2QZ0DJbuG6HWvmHCqZPJ6dbuxFnIqEgYsZOJglJQZD4CDGoQ/mQ
zWI9DkAYYf6CTLvhn6DVuw9vXxUHYhg4i//8vMMc0V5gloF5rVnhef8hLZtMIDnb
mUN5FH7qAQiNfq+CCAYDN3EzkPVKEc2s1Ce8qRDN1TN6Jn+YnXYjxKce2oysx8d6
sb9cSmS7YOlvpo73at3PKZGFvlu41j5Sc2irspESGR2Onyt1jlgkemAsi7a01u7m
cO3wXuiKJgth0DNgKpRIPTK0bciYX9zq2rYKsSfYCoVDkXU/gdEtLmQqjciPUJuH
we6ptGhDjUv7GIYr3Tpny6IUmVO5AnA1T2tF5T0BTcSgRpmsOnpRW3TrDhHDD2Sf
E1WwGO9UJ8cevTy0RLeT
=VTdd
-END PGP SIGNATURE-

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 09 Jan 2016 11:09:00 -0800, Russ Allbery 
wrote:
>For one specific example, it's become quite clear over the past year that
>systemd has achieved the same status as abortion debates in US politics.
>Not only is it clear that we will *never* stop arguing about systemd,
>opposition to or support of systemd has turned into a tribal identity
>marker for at least some people.  Those who disagree aren't just
>prioritizing different things, or even just wrong, but are actively evil,
>horrible people who should be shunned.  This is hugely demoralizing and
>hugely off-putting.  While it is by far not the only thing that has led to
>me not spending as much time on Debian over the past year plus, it's
>certainly been a factor.

I disagree with this point of view.

The technical problem with systemd is its inflexibility. It can do
about 80 % of things that the alternatives were able to. It does those
80 % exceptionally well, with clear design and good documentation.

Unfortunately, getting the 20 % to reach the old feature set is almost
impossible since systemd's upstream is fiercely opposed to implement
things that they themselves don't deem necesary, and they're also
opposed to add documented interfaces that would allow local additions
to be hooked in.

I am not even talking to go beyond the 100 % that we used to have with
the alternatives by using _their_ interfaces because systemd doesn't
have those interfaces.

It's simply unproductive to first having to argue with upstream if one
needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_
to wait for the next Debian stable release for this possibility to
become available, if I need to set this option for my network to work
_now_.

And it's simply frustrating to instinctively think "here should be a
variable" when writing a systemd unit because one cannot use a
variable here since systemd upstream thinks that it is unnecesary.

And it's quite arrogant to not implement things that ease starting
daeons that don't have their own configuration files, saying the
daemons should have configuration files and not rely on their command
line, hence systemd should not have features to make building daemon
command lines easier. Heck, some of those daemons have been around
since before systemd upsteam was born.

>This is obviously one of the biggest examples, but I don't think it's the
>only one.  There are numerous large and small examples that show up when
>people want to change how something has historically worked.

There is nothing wrong with change. There is a lot wrong with changes
that makes a significant portion of people's work harder and more
clumsy in the name of making things easier.

Of course this is something that will be discussed over and over again
because it makes people's live harder over and over again. One never
praises things that have become easier. But one will always blame
things that have become (unnecessaryil) harder, especially if the
hardship could be reduced by a bit more cooperation instead of
arrogance and dogmatism.

>And the pattern I've seen, time and time again, is that someone will come
>forward and say "look, I think this aspect of Debian is kind of broken,
>and has no real plausible path for getting better, and I think we should
>embrace this other way of solving the same problem."  And is met by people
>who are furious about the fact that the thing that is currently broken is
>not being fixed instead of putting effort into something new.

I think that greatly depends on how much existing functionality is
lost by this other way of solving the same problem.

>> It sees to me that it is because:
>
>> * I haven't been giving talks (or writing mailing list messages or
>>   manpages) where I attack people's beloved tools, data formats, or
>>   source code management practices.  I could certainly give such
>>   talks, but it would just serve to make me (more) enemies.
>
>In fact, you *have* done this occasionally.  You've been vocal about
>things that you think are broken or insane or horrible, using terms like
>that.  I remember hearing several of them in person.  :)  For example, I
>recall you not being much of a fan of how 3.0 (quilt) packages work.

And, additionally, Ian sounds pretty different when one _reads_ what
he wrote or when he is _heard_ saying those exact same words. My
perception of Ian has changed a lot (in a positive way!) when meeting
him in person at Debconf.

>Another good recent example (well, "recent"; the debate has drug out over
>*years*, which is typical) is the Debian menu vs. desktop files argument,
>which went all the way to the TC, got a TC decision, and now still isn't
>completely settled because there's a separate Policy argument.

Yes, it's another change that kills existing functionality without a
real replacement.

Or can I have an executable that generates virtual .desktop files on
the fly as I can with Debian menu?

>To me, this is far more of a social issue than a 

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 09:31:36 +0200, Lars Wirzenius  wrote:
>On Fri, Jan 08, 2016 at 01:31:12PM -0800, Russ Allbery wrote:
>> What will kill Debian faster than anything else is to have every idea for
>> changing something large, interesting, or possibly revolutionary in Debian
>> be met with anger, derision, and attacks.
>
>Hear, hear. I snipped out the rest of Russ's mail, but only for
>brevity: I fully agree with all of it. Extremely well said, Russ.
>
>I feel that there is fair bit of unresolved conflict sloshing around
>the project. This happens when people have a disagreement, and it's
>not handled properly on an emotional level: even though the
>disagreement is resolved on a technical level, and a decision is made
>and implemented, those who didn't agree with it don't get proper
>emotional closure, they feel put upon and rejected, that their
>concerns do not matter. It's like they are wounded, and the wound
>never gets to heal, and if there's any future disagreement, the old
>wound gets torn open again. That's not healthy.

Yes, that's pretty well said as well. Exactly how I feel. And I am not
even a systemd opponent.

>What could we do instead, to prevent and to handle these things?

It would help to be friendly to each other. No CoC needed by that,
it's just basic common sense.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 11:14:53 +, Neil Williams 
wrote:
>On Sat, 9 Jan 2016 18:32:28 +0800
>Paul Wise  wrote:
>> On Sat, Jan 9, 2016 at 1:41 AM, Marc Haber wrote:
>> 
>> > Yes, I have heard your (it was you, wasn't it) talk in Heidelberg. I
>> > took with me that you plan to adopt a "once you're out of testing,
>> > you're out of stable for the next release, unless you're really
>> > really important" policy for stretch, which has put me in deep
>> > worry.  
>> 
>> Packages often get autoremoved from testing and then go back in
>> quickly once they are fixed, so I'm not sure that is correct.
>
>So this phrase:
>
>[during the latter half of our freeze] 
>> > "once you're out of testing,
>> > you're out of stable for the next release, unless you're really
>> > really important"
>
>*is* correct *if* the original prefix is retained - and it shouldn't
>overly worry any developers. It's a necessary step to actually getting a
>release.

Are you actually saying that hamm, slink, woody, sarge, lenny,
squeeze, wheezy and jessie haven't been releases? We actually did
pretty well without that rule, and I find it deeply disturbing that
people are suddenly claiming that this - imo harmful - rule is
absolutely necessary to get a release.

There was a time when we released when it was finished. Now it seems
like we aim to release at all cost when the calendar says that we
should.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 16 Jan 2016 17:12:02 +0100, Vincent Bernat 
wrote:
> ? 16 janvier 2016 16:38 +0100, Marc Haber  :
>> It's simply unproductive to first having to argue with upstream if one
>> needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_
>> to wait for the next Debian stable release for this possibility to
>> become available, if I need to set this option for my network to work
>> _now_.
>
>You seem to always take vague examples to avoid being contradicted. You
>can execute any unit before and after network is setup through the
>dependency system.

Show me how to set a certain option to a VLAN interface that is
created by /etc/systemd/network/foo.netdev and needs to be set before
the interface is taken "up" by /etc/systemd/network/foo.network. Both
unit files are processed by the same systemd-networkd.service with no
hook in between.

>If you need to set some sysctl after an interface has
>been configured, just do it:

Yes. Easy in theory.

>> And it's quite arrogant to not implement things that ease starting
>> daeons that don't have their own configuration files, saying the
>> daemons should have configuration files and not rely on their command
>> line, hence systemd should not have features to make building daemon
>> command lines easier. Heck, some of those daemons have been around
>> since before systemd upsteam was born.
>
>And they seem to work fine with systemd. Upstream is pushing for people
>to just write an override. But we are free to use EnvironmentFile=.

People in the systemd community are asking us to not use
EnvironmentFile or otherwise Lennart might feel forced to remove it
since we're all using it wrong.

This is what gets me absolutely furious.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 15:59:33 +, Ian Jackson
 wrote:
>But I have had, in general, good support from almost all quarters.
>Almost no-one has tried to discourage me, and there has been no anger,
>derision, or attacks.  The main limiting factor has been my own
>available effort, and the complexity of the task.
>
>Why do you think I have had such an `easy ride' ?  I doubt it's
>because I'm popular and everyone just naturally wants to help  me.
>
>It sees to me that it is because:
>
>* I haven't been giving talks (or writing mailing list messages or
>  manpages) where I attack people's beloved tools, data formats, or
>  source code management practices.  I could certainly give such
>  talks, but it would just serve to make me (more) enemies.
>
>* The new mechanisms I am developing and implementing are designed, on
>  a technical level, to interoperate with existing systems.
>
>* Insofar I foresee that anything that currently exists may eventually
>  be obsoleted, I am avoiding talking about it (except perhaps if you
>  catch me in the bar or the pub).  In large part this is because I
>  recognise that existing things should be deliberately removed only
>  when the their users and developers will be happy with the
>  replacement.
>
>In short, I haven't been throwing my weight around.

I think it is mainly interoperability. dgit can safely be ignored,
everyone can continue as usual and only take a look a dgit when one
feels like it. Also, dgit doesn't make me lose features of my favorite
toolchain that I deem important to me.

Migrations such as systemd and UsrMerge do hit all of us, without us
wanting or not. This is a completely different deal, especially when
one knows that the people behind those migrations are not easy to deal
with. Additionally, beloved and important functionality is lost in
those migrations, and the people behind them saying "everythin you
have done up to now has been wrong for all the time, you're lucky that
it didn't explode before, be happy that we make it deliberately
explode" causes a great deal of distrust.

>I could mention a couple of other projects in Debian that are fairly
>big changes: source-only uploads, and reproducible builds.  It seems
>to me that the folks doing those exciting and worthwhile projects are,
>in general, getting support and encouragement from the project as a
>whole.

All of them can safely be ignored in daily packaging practice. I don't
mind adding a few patches to help, but I don't need to change my work
so severely as systemd/UsrMerge wants me to do.

I am not saying that source-only uploads and reproducible builds don't
make me lose features. Actually, making one of my packages build
reproducibly forced me to remove a sanity check that alerts a package
builder if some vital part of the documentation changed upstream.

>Even multiarch, which is very complicated and was fiercely contested
>on the technical level, has now made it in and even involved
>relatively low levels of aggro - even though on a technical level we
>are even now still working through some of fallout.

I have never understood why multiarch was so much fought about, the
migration was rather pretty painless and it was not such big change.

>I think that people who want to change Debian should take care to:
>
>  - Communicate respectfully;
>  - Ensure technical interoperability between different
> approaches and different tools;
>  - Carefully plan necessary transitions;
>  - Approach change in a consensual manner;
>  - Particularly, avoid hostile acts like publicly declaring
> other people's code or configurations dead or unsupported.

- don't deliberately break other people's setups just beause you think
the way those setups were made was broken anyhow for years.

Amen.

>It is not necessary to declare other people's code or configurations
>dead in order to make progress.  New things can sit alongside old
>things.  Eventually the new things will be overwhelmingly popular
>because they are better, and no-one will want to work on the old
>things, which can then wither away.  And if the old things don't
>wither away because a few people still want to maintain them, well,
>fine - that's them exercising their software freedom.

Right!

And don't reduce people's freedom from "having the configuration a tad
bit different" to "you're free to use an entirely different software",
especially if that really means going away from Debian.

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

Re: support for merged /usr in Debian

[Vincent Bernat]

 ❦ 16 janvier 2016 16:38 +0100, Marc Haber  :

> It's simply unproductive to first having to argue with upstream if one
> needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_
> to wait for the next Debian stable release for this possibility to
> become available, if I need to set this option for my network to work
> _now_.

You seem to always take vague examples to avoid being contradicted. You
can execute any unit before and after network is setup through the
dependency system. If you need to set some sysctl after an interface has
been configured, just do it:

#v+
[Service]
Type=oneshot
ExecStart=/sbin/sysctl -w net.=...
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[Unit]
Description=Enable some unknown IPv6 feature now
After=sys-subsystem-net-devices-eth0.device
#v-

> And it's quite arrogant to not implement things that ease starting
> daeons that don't have their own configuration files, saying the
> daemons should have configuration files and not rely on their command
> line, hence systemd should not have features to make building daemon
> command lines easier. Heck, some of those daemons have been around
> since before systemd upsteam was born.

And they seem to work fine with systemd. Upstream is pushing for people
to just write an override. But we are free to use EnvironmentFile=.
-- 
And do you think (fop that I am) that I could be the Scarlet
Pumpernickel?


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Philipp Kern]

On Sat, Jan 16, 2016 at 04:07:12PM +0100, Marc Haber wrote:
> There was a time when we released when it was finished. Now it seems
> like we aim to release at all cost when the calendar says that we
> should.

No. We always ignored the last bunch of bugs. At some point you need to
make the call that we're going to release. The freeze is a burden on
the developers, so getting rid of packages the maintainers do not care
about and nobody else knows how to rescue or to argue why the problem
should be ignored for $release is one way to relieve the burden on
others. In short you cannot hold the project hostage.

Kind regards
Philipp Kern

Re: support for merged /usr in Debian

[Vincent Bernat]

 ❦ 16 janvier 2016 17:37 +0100, Marc Haber  :

>>You seem to always take vague examples to avoid being contradicted. You
>>can execute any unit before and after network is setup through the
>>dependency system.
>
> Show me how to set a certain option to a VLAN interface that is
> created by /etc/systemd/network/foo.netdev and needs to be set before
> the interface is taken "up" by /etc/systemd/network/foo.network. Both
> unit files are processed by the same systemd-networkd.service with no
> hook in between.

#v+
[Service]
Type=oneshot
ExecStart=/usr/bin/ip a l
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[Unit]
Description=Enable some unknown IPv6 feature now
After=sys-subsystem-net-devices-vlan1.device
Requires=sys-subsystem-net-devices-vlan1.device
Before=sys-devices-virtual-net-vlan1.device
Conflicts=sys-devices-virtual-net-vlan1.device
#v-

(I am using /usr/bin/ip because I am testing this on CoreOS which comes
with networkd already enabled and they have a merged /usr).

#v+
[Match]
Name=vlan1

[Network]
Address=10.1.10.9/24
#v-

In journalctl:

Jan 16 19:09:18 localhost ip[494]: 3: vlan1@eth0: 
 mtu 1500 q
Jan 16 19:09:18 localhost ip[494]: link/ether b2:2b:bb:35:34:85 brd 
ff:ff:ff:ff:ff:ff
Jan 16 19:09:18 localhost ip[494]: inet6 fe80::b02b:bbff:fe35:3485/64 scope 
link tentative
Jan 16 19:09:18 localhost ip[494]: valid_lft forever preferred_lft forever

Of course, vlan1 is up because with networkd, configuring the "netdev" makes
it up while in Debian, setting the IP makes it up. However, I don't see
you whining about the lack of flexibility in Debian where you cannot
execute a command when the interface is up but before it gets an IP. If
you needed to do that, you would just use "inet manual" and do whatever
you want. That's the same with systemd, just use a unit.

>>And they seem to work fine with systemd. Upstream is pushing for people
>>to just write an override. But we are free to use EnvironmentFile=.
>
> People in the systemd community are asking us to not use
> EnvironmentFile or otherwise Lennart might feel forced to remove it
> since we're all using it wrong.
>
> This is what gets me absolutely furious.

Already debunked here:
 https://lists.debian.org/debian-devel/2016/01/msg00384.html

Also:
 https://lists.debian.org/debian-devel/2016/01/msg00075.html

I hope that the systemd community doesn't see you as representative of
the Debian community.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Michael Biebl]

Am 16.01.2016 um 23:38 schrieb Philipp Kern:
> On Sat, Jan 16, 2016 at 04:07:12PM +0100, Marc Haber wrote:
>> There was a time when we released when it was finished. Now it seems
>> like we aim to release at all cost when the calendar says that we
>> should.
> 
> No. We always ignored the last bunch of bugs. At some point you need to
> make the call that we're going to release. The freeze is a burden on
> the developers, so getting rid of packages the maintainers do not care
> about and nobody else knows how to rescue or to argue why the problem
> should be ignored for $release is one way to relieve the burden on
> others. In short you cannot hold the project hostage.

Amen. I'm much happier how the last couple of releases were handled. The
release team(s) did an outstanding job.
And things like autoremovals are a god send. I'd like to see more of
those automated QA checks which weed out unmaintained packages.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?




signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Nikolaus Rath]

On Jan 10 2016, Eric Valette  wrote:
> Russ Allbery writes:
>
>> For one specific example, it's become quite clear over the past year that
>> systemd has achieved the same status as abortion debates in US politics.
>> Not only is it clear that we will *never* stop arguing about systemd,
>> opposition to or support of systemd has turned into a tribal identity
>> marker for at least some people.
>
> Your example comparing systemd debate vs abortion debate is
> definitively insane :
[...]

Point proven. Were it not for the length of your email, I would have
believed you did that deliberately.


Best,
-Nikolaus

(No Cc on replies please, I'm reading the list)
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Re: support for merged /usr in Debian

[Jonathan Dowland]

On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote:
> Your example comparing systemd debate vs abortion debate is definitively
> insane
snip
> ...(at least here in France).

Russ specifically said "in US politics". His analogy was very clearly bracketed
to the situation in the US, *not* in France. Ipso Facto, you have misunderstood
his analogy.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

Re: support for merged /usr in Debian

[Tom H]

On Wed, Jan 6, 2016 at 12:03 AM, Philipp Kern  wrote:
> On 2016-01-04 11:30, Marc Haber wrote:
>>
>> Please also notice that this is the only option for ExecStart in
>> systemd units. Well played, Lennart.
>
> Similarly skeleton-based init scripts use the full path as well. It helps if
> you can stat() it. Which, I guess, you could by extension by using "which"
> and the like. On the other hand init scripts are supposed to be runable in
> "env -i". Now, what would the PATH be for systemd to use? My skeleton-based
> init scripts ship their own PATH (yay, duplication and decentral
> configuration). I can see how you would want to use EnvironmentFile for
> that. But then, why not simply override ExecStart? And even then I don't see
> the point. (One reply would be "to reuse the distro-provided commandline
> arguments", which is fair, but you are already redirecting the path to the
> binary from the default anyway and are not using the distro one.)
>
> You can continue to childishly blame Lennart for everything, but that might
> cause others to stop taking you seriously. Which isn't really what you
> deserve.

Lennart didn't even say that he wanted to get rid of "EnvironmentFile=".

>From the same-named thread on systemd-devel@:

--- 8< ---
1)
I probably should never have added EnvironmentFile= in the first place.

2)
I think EnvironmentFile= was a mistake, and I explained why. But then
again, I am not planning to remove it, and I never suggested that.
--- >8 ---

He advocated the use of drop-ins, as you (Philipp) do.

There's one daemon (that I use) where this is a PitA; nfsd and its
associated executables. It would mean having to edit multiple units
rather than two files on Debian/Ubuntu and one file on Gentoo/RHEL.

Re: Re: support for merged /usr in Debian

[Eric Valette]

Russ Allbery writes:


For one specific example, it's become quite clear over the past year that
systemd has achieved the same status as abortion debates in US politics.
Not only is it clear that we will *never* stop arguing about systemd,
opposition to or support of systemd has turned into a tribal identity
marker for at least some people.


Your example comparing systemd debate vs abortion debate is definitively 
insane : abortion is a philosophical debate that mainly roots whether 
you believe or not in god, which is not something that can be argued on 
its technical merits, or the fundamental compatibility problem it 
causes. The only point were your comparison makes sense is that 
communication by both opponent and proponent could have been better and 
less hostile (at least here in France).


Part of what ian said (copied below for ref), that has not been done 
with systemd is definitively the root cause of all the systemd debate



I think that people who want to change Debian should take care to:

  - Communicate respectfully;
  - Ensure technical interoperability between different
 approaches and different tools;
  - Carefully plan necessary transitions;
  - Approach change in a consensual manner;
  - Particularly, avoid hostile acts like publicly declaring
 other people's code or configurations dead or unsupported.


I have been criticizing systemd introduction in this newgroup/mailing 
lists because, at the beginning, it did break nearly all my systems, 
whereas it should not had:


	1) when you find /proc/config.gz and you know that some feature are 
required for systemd, you could check before installing it and avoid 
removing sysv init system even if mots pelple do use distribution kernel 
(without /proc/config.gz you can write program that will check features 
via system calls).
	2) as it started to depend on libraries located in /usr, it did break 
on my system with no initrd, and different / and /usr and it did break 
my system at least 5 or six times before stabilizing. I suggested to add 
a script to make sure sysdemd binary does not link with /usr located 
libraries to detect this before crashing people installations,


So this are clear example were simple technique could have been used to 
avoid breaking installed systems. It does cost a bit more effort but 
would have generated far less heated debate and meybe even les work at 
the end.


Now I do see benefits of systemd (boot faster) but the lack of easiness 
to define user modifiable parts (/etc/defaut/pkg) and things that are 
better left as the maintainer wants is still complicated and if you need 
to directly change default /lib/systemd/system/pkg.service its 
overridden during upgrade...


I have nas machines running debian without screen, video output, that 
have been installed via network and do not have easy way to repartition, 
not access to bootlodaer to install a different initrd, nor to repair 
other than soldering a serial line, so saying you should merge / and 
/usr or it may break and you will be on your own makes me less than 
happy. I thinks you can understand that.



I'll say it again: enthusiasm is fragile.  If we slap down excited people
every time they make intemperate comments out of enthusiasm, we lose SO
MUCH energy.  And I don't think we can afford to lose that much energy
from the project.


Agreed. But making transition smooth, may not cost that much and could 
preserve motivated people against hostile reactions if their changes 
breaks people habits/systems. So having a policy like Ian did propose 
for making fundamental changes may at the end avoid loosing energy..


--eric

Re: support for merged /usr in Debian

[Tom H]

Sorry. Not meant for list. :(

On Sun, Jan 10, 2016 at 9:59 AM, Tom H  wrote:
> Off-list.
>
> On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt  wrote:
>>
>> What is the advantage of having a optional-merged-/usr?
>
> Imagine the opposition if this had been proposed as a non-optional change!
>
> (BTW, I'll take this opportunity to thank you for two of your recent
> proposals, the re-work of the list of packages to be installed by
> default and the re-naming of the security suite. Thanks!)

Re: support for merged /usr in Debian

[Tom H]

Off-list.

On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt  wrote:
>
> What is the advantage of having a optional-merged-/usr?

Imagine the opposition if this had been proposed as a non-optional change!

(BTW, I'll take this opportunity to thank you for two of your recent
proposals, the re-work of the list of packages to be installed by
default and the re-naming of the security suite. Thanks!)

Re: Re: support for merged /usr in Debian

[Chris Bannister]

On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote:
> Russ Allbery writes:
> 
> >For one specific example, it's become quite clear over the past year that
> >systemd has achieved the same status as abortion debates in US politics.
> >Not only is it clear that we will *never* stop arguing about systemd,
> >opposition to or support of systemd has turned into a tribal identity
> >marker for at least some people.
> 
> Your example comparing systemd debate vs abortion debate is definitively
> insane : abortion is a philosophical debate that mainly roots whether you

Unbelievable!! What part don't you understand? He says it's "achieved
the same status", even I, understood at least that much. 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: support for merged /usr in Debian

[Simon McVittie]

On 10/01/16 11:09, Marc Haber wrote:
> Yes. But two of his militant fanbois suggested in the following that
> the option should be removed

Unfortunately, any sufficiently large community seems to have people
whose contributions are not entirely (or sometimes not at all)
constructive. I'm sure there are people in and around Debian whose
opinions you wouldn't want to be associated with, and not every
community has someone as patient and diplomatic as Russ moderating its
discussions.

S

Re: support for merged /usr in Debian

[Eduard Bloch]

Hallo,
* Eric Valette [Sun, Jan 10 2016, 02:16:50PM]:
> >On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote:
> >>Russ Allbery writes:
> >>
> >>>For one specific example, it's become quite clear over the past year that
> >>>systemd has achieved the same status as abortion debates in US politics.
> >>>Not only is it clear that we will *never* stop arguing about systemd,
> >>>opposition to or support of systemd has turned into a tribal identity
> >>>marker for at least some people.
> >>
> >>Your example comparing systemd debate vs abortion debate is definitively
> >>insane : abortion is a philosophical debate that mainly roots whether you
> >
> >Unbelievable!! What part don't you understand? He says it's "achieved
> >the same status", even I, understood at least that much.
> 
> "Achieved the same status" BUT for totally different fundamental reasons so

Are they?

> the reasoning is totally void. The analogy by itself, I let him the
> responsibility of comparing technical decisions to a matter of life or
> death

Nonsense. You can see these patterns everywhere. The next thing coming
to my mind are holy wars about bike chain maintenance...

http://sheldonbrown.com/chains.html
> [And a comment from John Allen: the problem becomes religious because it 
> addresses mysteries of existence, life and death (of chains...) to which 
> there is no clear and obvious answer -- as long as the chain is exposed to 
> dirt.

Regards,
Eduard.

-- 
 kde und tastatur? passt doch nicht mit dem nutzerprofil
"windepp" zusammen :)

Re: Re: support for merged /usr in Debian

[benjamin barber]

I agree, one is about a person's right to not be forced to have something
that they aren't able to support and will cause their life difficulty, the
other is about abortion

> Your example comparing systemd debate vs abortion debate is definitively
insane : abortion is a philosophical debate that mainly roots whether you
believe or not in god, which is not something that can be argued on its
technical merits, or the fundamental compatibility problem it causes. The
only point were your comparison makes sense is that communication by both
opponent and proponent could have been better and less hostile (at least
here in France).
>

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 10 Jan 2016 09:53:52 +0100, Tom H  wrote:
>On Wed, Jan 6, 2016 at 12:03 AM, Philipp Kern  wrote:
>Lennart didn't even say that he wanted to get rid of "EnvironmentFile=".
>
>>From the same-named thread on systemd-devel@:
>
>--- 8< ---
>1)
>I probably should never have added EnvironmentFile= in the first place.
>
>2)
>I think EnvironmentFile= was a mistake, and I explained why. But then
>again, I am not planning to remove it, and I never suggested that.
>--- >8 ---
>
>He advocated the use of drop-ins, as you (Philipp) do.

Yes. But two of his militant fanbois suggested in the following that
the option should be removed because of Lennarts reasoning. In the
following, one of them said that if the option will be removed in the
future, it would be "our" because "we" had been using the option
"wrong" and have thus "forced lennart" to remove it since we refused
to be "educated" about "proper" use of systemd.

This is what got me furious. I am not here to be educated. I am here
to use software. What is the business of the systemd community to tell
me how I am to do my work?

Lennart is not always at fault. He has his problems with differing
opinions, but at least his reasoning is usually sound. The bigger
problems are his followers, most of them emulating his social behavior
because they think it's fine (I think the word is "role model"), but
without being this technically brilliant.

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

Re: Re: Re: support for merged /usr in Debian

[Eric Valette]

On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote:

Russ Allbery writes:

>For one specific example, it's become quite clear over the past year that
>systemd has achieved the same status as abortion debates in US politics.
>Not only is it clear that we will *never* stop arguing about systemd,
>opposition to or support of systemd has turned into a tribal identity
>marker for at least some people.

Your example comparing systemd debate vs abortion debate is definitively
insane : abortion is a philosophical debate that mainly roots whether you


Unbelievable!! What part don't you understand? He says it's "achieved
the same status", even I, understood at least that much.


"Achieved the same status" BUT for totally different fundamental reasons 
so the reasoning is totally void. The analogy by itself, I let him the 
responsibility of comparing technical decisions to a matter of life or 
death


-- eric

Re: md5(3bsd) (was: Re: support for merged /usr in Debian)

[Bastien Roucaries]

Le 8 janvier 2016 23:54:41 GMT+01:00, m...@linux.it a écrit :
>On Jan 08, Robert Edmonds  wrote:
>
>> If it really does need to do MD5, maybe it could use the one in
>libbsd0
>> instead of dragging in libgnutls-openssl27 and its dependencies.
>I did not notice this recent addition...
>Folks, there is *a lot* of software which embeds copies of md5.c:
>please 
>try to convert it to use libbsd!
>And how many of you still have copies of setproctitle.c around? Do you 
>know that they probably come from sendmail? Clean up your old code!
>
>If you have some old package with plain makefiles which needs to be 
>converted to use libbsd then you can have a look at my openbsd-inetd 
>package for inspiration.

We coule add a Lintian warning for both. Care to open a bug?

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: support for merged /usr in Debian

[Neil Williams]

On Sat, 9 Jan 2016 18:32:28 +0800
Paul Wise  wrote:

Rather a critical element has been snipped there, Paul, sadly.

On Fri, 8 Jan 2016 15:42:07 +, Niels Thykier 
wrote:
> Given the latter half of our
>freeze tends to involve mostly frustration, fragmentation of developers
>and very few bug fixes, I am personally one of the people, who would
>like to see Debian have shorter freezes[1].  

> On Sat, Jan 9, 2016 at 1:41 AM, Marc Haber wrote:
> 
> > Yes, I have heard your (it was you, wasn't it) talk in Heidelberg. I
> > took with me that you plan to adopt a "once you're out of testing,
> > you're out of stable for the next release, unless you're really
> > really important" policy for stretch, which has put me in deep
> > worry.  
> 
> Packages often get autoremoved from testing and then go back in
> quickly once they are fixed, so I'm not sure that is correct.

So this phrase:

[during the latter half of our freeze] 
> > "once you're out of testing,
> > you're out of stable for the next release, unless you're really
> > really important"

*is* correct *if* the original prefix is retained - and it shouldn't
overly worry any developers. It's a necessary step to actually getting a
release.

However, this is so far off-topic now that it is pointless to continue.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpAFN0gH052q.pgp
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Jonathan McDowell]

On Fri, Jan 08, 2016 at 07:09:59PM +0100, Marc Haber wrote:
> On Fri, 8 Jan 2016 17:54:49 +, Jonathan McDowell
>  wrote:
> >You're not communicating clearly and this is indeed causing problems
> >in this thread. You said "all my clients run unstable", not "all my
> >client machines run unstable". You've also later said "I've not
> >installed any new Debian systems at any client site". It is not
> >unreasonable that the casual reader will assume you are using the
> >term to mean a 3rd party who you are managing system for.
> 
> You're right to blame for only speaking english for 30 years of my
> life and living in a country where TV programs are dubbed. I am also
> deeply worried about the Operating System I still care about after 15
> years and which works so hard to feel not like a home any more.

I'm not sure how you've taken any of this meaning from my message. You
have inconsistently used certain terms such that it's not surprising
they have been misunderstood by others in this thread. I am not in any
way complaining about your grasp of the English language.

> >To attempt to add some signal to my noise, the gist of this thread seems
> >to be that Marco wants to make it easy for those who wish to have a
> >merged /usr to do so, and is not planning to force this upon anyone.
> 
> I would believe that if it were somebody else.

If you are going to assume bad faith on the parts of other developers
then it is very unlikely you will see a satisfactory resolution of this
discussion. It doesn't seem a helpful way to view your interactions with
the project. I'll accept Marco's style can be very abrupt, but having a
knee-jerk reaction that he must be up to no good is not helpful.

> >As far as I can tell what he wants to happen is a) files in / and
> >/usr locations not to conflict and b) policy to state that this
> >should be the case.
> 
> If that is really the gist of those editorial changes[1], then this is
> actually a misunderstanding. Maybe UsrMerge is even a misnomer.

These are not editorial changes. There's a clear desire for a change in
the way things are handled, and I don't believe there is any need to
ascribe an ulterior motive to it. Marco wants to be able to merge / and
/usr on his systems. Various other people do as well. If we, as a
project, say that we should not have duplicate file names between these
portions of the file system then they can have their desire and the rest
of us can continue to keep them separate.

It seems to me to be one of those requests that really doesn't cause an
imposition on those who can't care about the change (or even actively
don't want to do it), while being really quite helpful to those who want
to do things a bit differently.

J.

[1] NMF.

-- 
   101 things you can't have too   |  .''`.  Debian GNU/Linux Developer
   much of : 48 - Pies.| : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Paul Wise]

On Sat, Jan 9, 2016 at 1:41 AM, Marc Haber wrote:

> Yes, I have heard your (it was you, wasn't it) talk in Heidelberg. I
> took with me that you plan to adopt a "once you're out of testing,
> you're out of stable for the next release, unless you're really really
> important" policy for stretch, which has put me in deep worry.

Packages often get autoremoved from testing and then go back in
quickly once they are fixed, so I'm not sure that is correct.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: support for merged /usr in Debian

[Paul Wise]

On Sat, Jan 9, 2016 at 7:14 PM, Neil Williams wrote:

> Rather a critical element has been snipped there, Paul, sadly.

Thanks for pointing out my error, sorry for the noise.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: support for merged /usr in Debian

[Ian Jackson]

Russ Allbery writes ("Re: support for merged /usr in Debian"):
> What will kill Debian faster than anything else is to have every idea for
> changing something large, interesting, or possibly revolutionary in Debian
> be met with anger, derision, and attacks.

I know you are engaging in hyperbole, but really, I think this is
quite unjustified.

While there is much that I agree with in your message, particularly
about the relationship between maintenance, creativity and fun, I
think you're way off the mark in the paragraph I quote above.


In the last few years I have embarked on a campaign to change the way
Debian manages its source code.  Of course it's just me, and even so
it's only getting some of my own effort, so it's not going as rapidly
as it could.

But I have had, in general, good support from almost all quarters.
Almost no-one has tried to discourage me, and there has been no anger,
derision, or attacks.  The main limiting factor has been my own
available effort, and the complexity of the task.

Why do you think I have had such an `easy ride' ?  I doubt it's
because I'm popular and everyone just naturally wants to help  me.

It sees to me that it is because:

* I haven't been giving talks (or writing mailing list messages or
  manpages) where I attack people's beloved tools, data formats, or
  source code management practices.  I could certainly give such
  talks, but it would just serve to make me (more) enemies.

* The new mechanisms I am developing and implementing are designed, on
  a technical level, to interoperate with existing systems.

* Insofar I foresee that anything that currently exists may eventually
  be obsoleted, I am avoiding talking about it (except perhaps if you
  catch me in the bar or the pub).  In large part this is because I
  recognise that existing things should be deliberately removed only
  when the their users and developers will be happy with the
  replacement.

In short, I haven't been throwing my weight around.


I could mention a couple of other projects in Debian that are fairly
big changes: source-only uploads, and reproducible builds.  It seems
to me that the folks doing those exciting and worthwhile projects are,
in general, getting support and encouragement from the project as a
whole.

Even multiarch, which is very complicated and was fiercely contested
on the technical level, has now made it in and even involved
relatively low levels of aggro - even though on a technical level we
are even now still working through some of fallout.


It is true that all of these projects are taking years to come to
fruition.  But doing things carefully and with proper transition
planning means that Debian as a whole can be changing many things all
at once.  The lead time is long but our productivity is high.

I think that people who want to change Debian should take care to:

  - Communicate respectfully;
  - Ensure technical interoperability between different
 approaches and different tools;
  - Carefully plan necessary transitions;
  - Approach change in a consensual manner;
  - Particularly, avoid hostile acts like publicly declaring
 other people's code or configurations dead or unsupported.

It is not necessary to declare other people's code or configurations
dead in order to make progress.  New things can sit alongside old
things.  Eventually the new things will be overwhelmingly popular
because they are better, and no-one will want to work on the old
things, which can then wither away.  And if the old things don't
wither away because a few people still want to maintain them, well,
fine - that's them exercising their software freedom.

Ian.

Re: support for merged /usr in Debian

[Russ Allbery]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: support for merged /usr in Debian"):

>> What will kill Debian faster than anything else is to have every idea
>> for changing something large, interesting, or possibly revolutionary in
>> Debian be met with anger, derision, and attacks.

> I know you are engaging in hyperbole, but really, I think this is
> quite unjustified.

I'm not actually intending to engage in hyperbole, and I do think it's a
quite justified fear.  Now, there is a legitimate debate about how much
that's actually *happening*, and I concur with your critique that I may be
overstating how much it happens.  But I stand by my statement of the risk.

For one specific example, it's become quite clear over the past year that
systemd has achieved the same status as abortion debates in US politics.
Not only is it clear that we will *never* stop arguing about systemd,
opposition to or support of systemd has turned into a tribal identity
marker for at least some people.  Those who disagree aren't just
prioritizing different things, or even just wrong, but are actively evil,
horrible people who should be shunned.  This is hugely demoralizing and
hugely off-putting.  While it is by far not the only thing that has led to
me not spending as much time on Debian over the past year plus, it's
certainly been a factor.

This is obviously one of the biggest examples, but I don't think it's the
only one.  There are numerous large and small examples that show up when
people want to change how something has historically worked.

> In the last few years I have embarked on a campaign to change the way
> Debian manages its source code.  Of course it's just me, and even so
> it's only getting some of my own effort, so it's not going as rapidly as
> it could.

> But I have had, in general, good support from almost all quarters.
> Almost no-one has tried to discourage me, and there has been no anger,
> derision, or attacks.  The main limiting factor has been my own
> available effort, and the complexity of the task.

> Why do you think I have had such an `easy ride' ?  I doubt it's because
> I'm popular and everyone just naturally wants to help me.

I believe it's because it's a different kind of change.  You're not
changing how Debian systems *work*.  You're providing a new tool that can
be used in developing Debian itself.

This has always been much easier, for numerous reasons.  One is that we
collectively seem to be much more mentally flexible about our tools than
about OS functionality.  Another is that debates over tools don't bring in
as many people who are not themselves currently contributing to Debian
development, but who have very strong opinions about how Debian should
function once installed.  And a third is that it's far easier to maintain
a wide collection of tools and let people choose, because tools pose fewer
integration constraints.

I was instead talking about changes to the Debian user experience, not
just the stuff we use internally inside the project to produce Debian.
And the pattern I've seen, time and time again, is that someone will come
forward and say "look, I think this aspect of Debian is kind of broken,
and has no real plausible path for getting better, and I think we should
embrace this other way of solving the same problem."  And is met by people
who are furious about the fact that the thing that is currently broken is
not being fixed instead of putting effort into something new.

Often we can even get some agreement that the current stuff is kind of
broken, and often they have no more idea of how we can feasibly fix the
current system than anyone else.  But the idea of admitting that it's
broken and isn't likely to get any better, or indeed is likely to get
worse, seems to be rage-provoking and produces these huge threads that
degenerate into increasing anger, threats to stop using Debian,
accusations that other people are destroying Debian by trying to improve
it, and so forth.

I think people have the mistaken impression that Marco and a few others
somehow provoke a disproportional number of these arguments.  I don't
think they do.  I think the difference is that Marco is willing to dig in
his heels and keep reiterating (sometimes not all that poltely, I admit)
the point he's trying to make, rather than backing down and going away.
So you actually notice the argument.  If one is less confrontational and
willing to take the flamewar, it's much, much easier to just walk away.
And then there is indeed no contentious argument... and also no one
working on the problem any more, because anyone who was thinking about
working on it looks at that discussion and thinks "wow, I don't want any
piece of that."

> It sees to me that it is because:

> * I haven't been giving talks (or writing mailing list messages or
>   manpages) where I attack people's belove

Re: support for merged /usr in Debian

[Marc Haber]

On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
wrote:
>On 2016-01-04 11:30, Marc Haber wrote:
>> On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
>> wrote:
>>> System admins do like using absolute path
>>> for security reasons...
>> Please also notice that this is the only option for ExecStart in
>> systemd units. Well played, Lennart.
>
>Similarly skeleton-based init scripts use the full path as well. It 
>helps if you can stat() it. Which, I guess, you could by extension by 
>using "which" and the like.

In init scripts, I can do that. In a systemd unit, I cannot. If I can,
this brings an ugliness to systemd units I would rather not have, as
this would mean losing one of the nicer systemd features. It just
saddens me that I have to introduce ugliness because my upstream
doesn't share my opinions of prettiness.

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

Re: support for merged /usr in Debian

[Christian Seiler]

On 01/08/2016 09:41 AM, Marc Haber wrote:
> On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
> wrote:
>> On 2016-01-04 11:30, Marc Haber wrote:
>>> On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
>>> wrote:
 System admins do like using absolute path
 for security reasons...
>>> Please also notice that this is the only option for ExecStart in
>>> systemd units. Well played, Lennart.
>>
>> Similarly skeleton-based init scripts use the full path as well. It 
>> helps if you can stat() it. Which, I guess, you could by extension by 
>> using "which" and the like.
> 
> In init scripts, I can do that. In a systemd unit, I cannot.

ExecStart=/bin/sh -c "something"

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Mon, 4 Jan 2016 13:51:48 +0100, Christian Seiler
 wrote:
>On 01/04/2016 12:15 PM, Marc Haber wrote:
>> On Mon, 04 Jan 2016 12:01:46 +0100, Ansgar Burchardt
>>> Remember that / and /usr don't have to reside on the same partition with
>>> the usrmerge proposal: they only have to be both available
>>> post-initramfs.  The initramfs already takes care to mount /usr (for the
>>> systemd case as initscripts needs updates for sysvinit as was said
>>> elsewhere).  So no repartitioning should be required on upgrades.
>> 
>> I'd like to have a positive confirmation that systemd upstream intends
>> to continue supporting this scheme and that Debian will also.
>
>Separate partitions mounted in the initramfs? The whole reason for the
>UsrMerge is to make a separate /usr filesystem more interesting - see
>the things in the proposal itself and what I've reiterated in [1].

Actually, having /usr mounted earlier increases the possibility of
something going wrong in early boot. This is good, since early boot is
the only part of Debian's boot process that still is reasonably
debuggable, but that will go away as well as soon as we have systemd
inside the initramfs as well, which will undoubtedly come sooner or
later. Debugging late system boot with the method one has been used to
for decades has already become considerably harder. Thankfully doing
so has not been necessary yet, which might be caused by the solid work
of the systemd people in Debian, who cannot be blamed for the
premature, Ubuntu-like freeze of jessie.

I am just afraid that initramfs' functionality will dramatically
change when systemd takes over initramfs as well, with a lot of
important functionality maked as "broken", "obsolete" and eventually
removed, just as the keyscript= feature of /etc/crypttab was lost a
year ago (noone cared).

The loss of keyscript just broke my clients. I am really afraid of the
first system update breaking my _servers_, causing a resinstall to be
necessary. I know of one customer who already said that if a reinstall
will become necessary, the reinstalled distribution will be called Red
Hat Enterprise Linux. I'd like to postpone this as long as possible.

>And
>the systemd developers are actively interested in things such as
>stateless systems or sharing /usr in containers etc.

Too bad that they have so little interest in the things that are
important to me. I still have to go through painful contortions to
have basic IPv6 functionality and configurability.

>Also, just from a technical perspective: systemd is also designed to
>work in containers, where filesystems are often already pre-mounted to
>their respective locations. So systemd must already cope with the fact
>that when it's started some mounts may already be present. If you
>couple that with the idea that the initrd mounts /usr, then it is
>trivially true that /usr can be separate, as long as it's already
>mounted before systemd is executed. That will hold true even IF systemd
>developers decide to drop support for mounting /usr from a running
>system. I'm not saying that somebody couldn't break that scenario if
>they tried really hard, but from a technical perspective.

What I am missing is a clearly worded commitment from upstream or
Debian not to break existing systems during upgrades.

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

Re: support for merged /usr in Debian

[Tollef Fog Heen]

]] Christian Seiler 

> On 01/08/2016 09:41 AM, Marc Haber wrote:
> > On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
> > wrote:
> >> On 2016-01-04 11:30, Marc Haber wrote:
> >>> On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
> >>> wrote:
>  System admins do like using absolute path
>  for security reasons...
> >>> Please also notice that this is the only option for ExecStart in
> >>> systemd units. Well played, Lennart.
> >>
> >> Similarly skeleton-based init scripts use the full path as well. It 
> >> helps if you can stat() it. Which, I guess, you could by extension by 
> >> using "which" and the like.
> > 
> > In init scripts, I can do that. In a systemd unit, I cannot.
> 
> ExecStart=/bin/sh -c "something"

This, or «ExecStart=/usr/bin/env food bar baz»

This is, as folks might have noticed, exactly the same limitation and
workaround as we have for #! lines in scripts.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: support for merged /usr in Debian

[Andrew Shadura]

On 8 January 2016 at 10:21, Marc Haber  wrote:
>>So let's say you installed lenny and had 512 MiB for / (with separate
>>/usr) because you thought back then that it was more than enough (more
>>than double the installed size) - and upgrade to Jessie will either run
>>out of disk space or come very close to it.
>
> Yes, this happens. Do we really have to _force_ this? It is annoying
> enough when it happens caused by the normal flow of things. Even if
> this is the case, not all systems will explode during the same system
> upgrades, allowing the local admin to spread those changes over two or
> even three releases. If we would, in some future, ship an upgrade that
> uncaringly would _require_ a repartitioning, this spread would not be
> possible, and it would undoubtedly call up management attention, which
> could in turn lead to management taking vendor decisions that we don't
> want.

Marc, please re-read the whole thread from the very beginning. Nobody
forces merged /usr on you.

-- 
Cheers,
  Andrew

Re: support for merged /usr in Debian

[Simon McVittie]

On 08/01/16 03:03, Marco d'Itri wrote:
> It has been said that some have[citation needed] crappy boot loaders 
> that do not support loading an initramfs, but you can still embed one in 
> the kernel binary if you are building your own kernel

... and you'd need to build your own kernel on these platforms in any
case, because Debian kernels (like those in most distributions) are
heavily modularized, and can't see a disk or mount the root filesystem
without help from user-space anyway (CONFIG_SATA_AHCI=m,
CONFIG_EXT4_FS=m and the equivalents for other drive interfaces and
filesystems).

tiny-initramfs, mentioned elsewhere in this thread, seems an excellent
candidate for embedding in a kernel that doesn't need a "full-fat"
initramfs: it's around 16K when statically linked to a small libc, and
is configured via the kernel command-line (to mount the root) and the
root's /etc/fstab (to mount /usr if necessary).

S

Re: support for merged /usr in Debian

[Marc Haber]

On Mon, 4 Jan 2016 13:38:15 +0100, Christian Seiler
 wrote:
>On 01/04/2016 11:41 AM, Marc Haber wrote:
>> On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery 
>> wrote:
>>> I do understand why people working in the embedded space care about some
>>> unusual mount orderings, file system separations, and very light cores,
>>> and I hope that we can accomodate and support all of their use cases
>>> inside Debian.  I think that's the most productive part of this thread.
>> 
>> We have already shown how "much" we care about the users of non-Linux
>> kernels in Debian ("not at all, they can happily go fishing").
>
>So why aren't you on the list of porters for either Hurd of kFreeBSD?

Since when does one have to actually work on something to be allowed
to find it important and interesting. You would have a point if you
told me to put better maintenance on the packages that I have taken
responsibility for instead of telling me to commit to do _more_ work
than I am already not properly doing.

>You could also say the same (not caring about them) of HA users: Jessie
>has no Pacemaker, because nobody cared about that during the Jessie
>release cycle. It was completely broken at that point and thus removed
>from the release.

Yes, that's really a pity.

>> And we're all doing this to keep our upstreams and Ubuntu happy.
>
>Have you read *any* of the technical arguments in this thread?
>
>(Btw. Ubuntu does NOT have UsrMerge. Ubuntu switched to systemd AFTER
>Debian decided to use systemd as default.)

My beef with Ubuntu is their release cycle and the fact that Debian is
being slowly modified to suit their cycle. Leaving behind Debian's
core values in the process.

>Btw. Is Debian there to mindlessly follow RedHat or Ubuntu?

In my opinion, no. Debian used to be there for technical leadership
and stability, living up to the name of the Universal Operating
System. Even if that meant not releasing once a year. Alas, times are
changing.

>> I, for example, am afraid of having to merge /usr in existing systems
>> during upgrades, causing repartitions to be necessary. I am afraid of
>> partition layout suddenly not fitting any more during an upgrade,
>> causing downtimes and customers considering to take the opportunity to
>> migrate to a really supported enterprise distribution.
>
>Sorry, but this is bogus, because this is a problem you have on every
>every upgrade. In the past I've already had to repartition systems
>because / had become too small, because the amount of software required
>to be there had grown (to support more storage solutions for mounting
>/usr) and also the kernel modules had grown.

If hundreds of megabytes of software would get moved from /usr to /,
this would certainly overflow my root file systems. In fact, as I have
understood things, software will move from / to /usr, making the
system completely unuseable if the multi-gigabytes /usr does not mount
for some reason.

The upside of this is that this will free up space in / which will be
needed for a dedicated recovery image. Too bad that we don't have such
a thing ourselves and have to recommend third-party products like grml
while at the same time making development of those third-party
products considerably harder by our release decisions.

>deboostrap of lenny (via archive.d.o) + kernel:
>313 MiB in total, 99 MiB on /usr  => 214 MiB on /
>debootstrap of jessie + kernel:
>618 MiB in total, 203 MiB on /usr => 415 MiB on /
>
>And that's just ONE kernel, if you upgrade you usually have additional
>kernels lying around. Plus I didn't install a lot of other utilities
>that are present on many systems, this is really minimal.

My standard Debian server image is about this size in total.

>So let's say you installed lenny and had 512 MiB for / (with separate
>/usr) because you thought back then that it was more than enough (more
>than double the installed size) - and upgrade to Jessie will either run
>out of disk space or come very close to it.

Yes, this happens. Do we really have to _force_ this? It is annoying
enough when it happens caused by the normal flow of things. Even if
this is the case, not all systems will explode during the same system
upgrades, allowing the local admin to spread those changes over two or
even three releases. If we would, in some future, ship an upgrade that
uncaringly would _require_ a repartitioning, this spread would not be
possible, and it would undoubtedly call up management attention, which
could in turn lead to management taking vendor decisions that we don't
want.

>If you also separate out
>/var the numbers game changes a bit, but the principle remains.

/var is of couse separated out on all but the smallest boxes.

>Also, the amount of space software requires on /usr is larger on
>Jessie - so even if your / partition is large enough, /usr might
>already be too small un upgrades.

_This_ will become more a problem when we force things onto /usr.

>I've also had the case 

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 18:37:11 +0100, Christian Seiler
 wrote:
>On 01/08/2016 10:21 AM, Marc Haber wrote:
>> If hundreds of megabytes of software would get moved from /usr to /,
>> this would certainly overflow my root file systems.
>
>That is not what is going to happen. Nobody ever proposed that. I
>don't know where people constantly get this idea...

We have been bitten by editorial changes in the past. The systemd
debate hasn't made things any easier. And I have over the last years
slowly lost part of my faith that Debian's key people (those that
don't get elected or delegated, but those that have control over key
packages) actually care about the _users_ of The Universal Operating
System.

Yes, I know, servers and buildds run without users, and caring about
users is not always more fun than actually doing development and
building sound, clean solutions.

>> making the
>> system completely unuseable if the multi-gigabytes /usr does not mount
>> for some reason.
>
>The system could also be unusable if / doesn't mount, or the kernel
>image is damaged, or...

Kernel Image and small / are less likely to get damaged than a
multi-gigabyte /usr. At least that's how people think who have known a
40 Meg (sic!) disk as "large". I am pretty well aware that my last
corrupted /usr file system was many years ago, but this is a change
one needs to get used to.

[correct reasoning removed]

>Well, but that can go both ways:
>
>1. /usr is too small, then UsrMerge will require repartitioning

I would probably be possible to have the script doing the merge check
whether /usr is large enough and abort if that is not the case. I
would write a wishlist report, but looking at who's in charge I know
that the answer would be "works for me, send a patch if you want this
change" anyway. And I don't like wasting my time, so I have made a
habit of looking into the maintainer field of debian/control and the
changelog of a package before bothering to write a wishlist report. Or
not write one.

[again, correct reasoning removed]

>> [Potential problems with the backup]
>
>I don't get your remarks:
>
>If you back up every file system with --one-file-system separately,
>(as you appear to be doing) other than the relative sizes of the
>backups (the /usr part is going to be larger, the / part smaller by
>the same amount) nothing at all should change.

One will probably need to adjust the anchor points of the file system
backups.

>> And I need
>> to change documentation, which will probably trigger a review process
>> with management attention.
>
>This may be very unfortunate for you, but I don't think a
>situation like yours should be the basis for deciding distribution
>policy.

Well, Debian is (still) used in big enterprises.

>If you want to "stay below the radar" of management, then you
>probably shouldn't dist-upgrade at all - because a lot more things
>can break on a software-level, where you need to adapt configuration.
>Or some software is discontinued and you have to switch to an
>alternative, where you have to redo your configuration completely.

I have been running Debian servers in production for nearly 20 years,
I can handle upgrades just fine. I just hate it when they are harder
than necessary for reasons that I can't follow.

>>>   Sure, you need to test if something breaks (because it always can,
>>>   regardless of whether UsrMerge is done or not), but _surely_ you
>>>   have a test environment before performing a dist-upgrade of your
>>>   entire production system? Right?
>> 
>> Not everywhere. This might look unprofessional, but I am usually
>> running the small little gallic Linux village inside "all Windows"
>> shops, and when I ask organizations for test environments, I might end
>> up with "nah, too much hassle, we'll just use Windows instead for your
>> job".
>
>And you can't even spin up a VM with the same size disk etc. to
>test things?

Not for every single machine.

>> You have a big point here. All I want is documentation and commitments
>> so that no surprises come.
>
>If I look at the Jessie release notes (Niels linked them somewhere
>in this thread), they are _very_ detailed, which is probably a big
>reason why the Jessie transition was far less painful as many
>people her have feared. So I don't think documentation will be an
>issue.

I'd prefer to read the commitment in the package itself.

[again, correct reasoning removed]

>2. The UsrMerge proposed here is optional and will remain so for
>Stretch.

... but not for buster

>Come to an agreement within the Debian project that supporting split
>/usr without an initramfs is not going to work out in the long term,

... but split /usr with initramfs is supported and will continue to be
a supported configuration at least in system upgrades.

>document that with an appropriate wording in the Stretch release notes.
>Suggest alternatives to real issues that people face because of this
>change (tiny-initramfs[1] for example). This way, while 

Re: support for merged /usr in Debian

[Jonathan McDowell]

On Fri, Jan 08, 2016 at 06:38:05PM +0100, Marc Haber wrote:
> On Fri, 8 Jan 2016 15:01:53 +, Jonathan Dowland 
> wrote:
> >and since you are running sid anyway, it wouldn't even help you, so
> >I'm puzzled why you suggested it.
> 
> You obviously don't see the difference between a customer, a client
> machine and a server. This might be a matter of language, so I'll
> explain it.

You're not communicating clearly and this is indeed causing problems in
this thread. You said "all my clients run unstable", not "all my client
machines run unstable". You've also later said "I've not installed any
new Debian systems at any client site". It is not unreasonable that the
casual reader will assume you are using the term to mean a 3rd party who
you are managing system for.

To attempt to add some signal to my noise, the gist of this thread seems
to be that Marco wants to make it easy for those who wish to have a
merged /usr to do so, and is not planning to force this upon anyone. As
far as I can tell what he wants to happen is a) files in / and /usr
locations not to conflict and b) policy to state that this should be the
case. I find it hard to object to this request, even without a merged
/usr approach.

There is a separate discussion which has been going on for much longer
which is about whether / and /usr are well supported as separate
filesystems, but that seems to have little to do with whether usrmerge
is undertaken or not.

J.

-- 
... "OK ... First I'll access the secret military spy satelite that is in
geosynchronous orbit over the midwest. Then I'll ID the limo by the
vanity plate "MR. BIGGG" and get his approximate position. Then I'll
reposition the transmission dish on the remote truck to 17.32 degrees
east, hit WESTAR 4 over the Atlantic, bounce the signal back into the
aerosphere up to COMSAT 6, beam it back to SATCOM 2 transmitter number
137 and down on the dish on the back of Mr. Big's limo... It's almost
too easy." -- Garth Algar, Wayne's World


signature.asc
Description: Digital signature

keyscript (was: Re: support for merged /usr in Debian)

[Christian Seiler]

On 01/08/2016 09:50 AM, Marc Haber wrote:
> The loss of keyscript just broke my clients.

I had an inspiration earlier and hacked this together:
https://gist.github.com/chris-se/9c0def7dca60d023d188

(Warning: not thoroughly tested, code is a quick hack and awful, might
do unexpected things. Also not documented. Quick howto: run make, copy
systemd-keyscript-cryptsetup to /lib/cryptsetup/, copy keyscript-generator
to /lib/systemd/system-generators, do systemctl daemon-reload and hope
for the best. systemd-cryptsetup will still warn about 'unknown option',
but it should work.)

(Interactive scripts obviously don't work, same thing as with
interactive init scripts, but if you need a password you can just use
PASS=$(systemd-ask-password "Some Message").)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 15:42:07 +, Niels Thykier 
wrote:
> Given the latter half of our
>freeze tends to involve mostly frustration, fragmentation of developers
>and very few bug fixes, I am personally one of the people, who would
>like to see Debian have shorter freezes[1].

Yes, I have heard your (it was you, wasn't it) talk in Heidelberg. I
took with me that you plan to adopt a "once you're out of testing,
you're out of stable for the next release, unless you're really really
important" policy for stretch, which has put me in deep worry.

I have not installed any new Debian systems at any client site since
hearing about these plans and I plan to keep it this way until I see
them fleshed out and lived.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 17:54:49 +, Jonathan McDowell
 wrote:
>You're not communicating clearly and this is indeed causing problems in
>this thread. You said "all my clients run unstable", not "all my client
>machines run unstable". You've also later said "I've not installed any
>new Debian systems at any client site". It is not unreasonable that the
>casual reader will assume you are using the term to mean a 3rd party who
>you are managing system for.

You're right to blame for only speaking english for 30 years of my
life and living in a country where TV programs are dubbed. I am also
deeply worried about the Operating System I still care about after 15
years and which works so hard to feel not like a home any more.

>To attempt to add some signal to my noise, the gist of this thread seems
>to be that Marco wants to make it easy for those who wish to have a
>merged /usr to do so, and is not planning to force this upon anyone.

I would believe that if it were somebody else.

>As
>far as I can tell what he wants to happen is a) files in / and /usr
>locations not to conflict and b) policy to state that this should be the
>case.

If that is really the gist of those editorial changes[1], then this is
actually a misunderstanding. Maybe UsrMerge is even a misnomer.

Greetings
Marc


[1] pun intended
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: keyscript (was: Re: support for merged /usr in Debian)

[Marc Haber]

On Fri, 8 Jan 2016 18:51:20 +0100, Christian Seiler
 wrote:
>(Warning: not thoroughly tested, code is a quick hack and awful, might
>do unexpected things. Also not documented. Quick howto: run make, copy
>systemd-keyscript-cryptsetup to /lib/cryptsetup/, copy keyscript-generator
>to /lib/systemd/system-generators, do systemctl daemon-reload and hope
>for the best. systemd-cryptsetup will still warn about 'unknown option',
>but it should work.)
>
>(Interactive scripts obviously don't work, same thing as with
>interactive init scripts, but if you need a password you can just use
>PASS=$(systemd-ask-password "Some Message").)

You're amazingly constructive. I wish I had your output. Thanks!

Will this handle a keyscript that needs to unlock another crypto LV
which is unlocked with a a password?

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

Re: support for merged /usr in Debian

[Russ Allbery]

Svante Signell  writes:

> No you are not. Debian following the commercial vendor track will make
> them extinguished. Technically there are no real advantages of the new
> (in many youngsters mind revolutionary) ideas. The idea of a Debian
> Universal Operating System, supporting Free Software (not Open Source
> Software), is dead.

What will kill Debian faster than anything else is to have every idea for
changing something large, interesting, or possibly revolutionary in Debian
be met with anger, derision, and attacks.  The process of proposing doing
interesting things inside Debian is already so miserable that it surprises
me people are willing to attempt it.  Those ideas are always met with
furious pushback from at least a few people who don't want anything to
ever change in that particular area of the distribution.  That this is
often different people for each change doesn't really help.

If it's not possible to do interesting things and it's not possible to try
to improve Debian, maintaining Debian becomes a job rather than something
one does for fun, which in turn will mean that Debian will become stale
and stagnant and lose contributors.  Then *everyone* loses, since even
those who would be happy to see absolutely nothing about the distribution
change expect incorporation of new software and support for new platforms
and new hardware.

If you want people to do maintenance work without getting to do anything
creative, interesting, or exciting, you had better have some method for
paying them, because that's a job, not something people do for the love of
it.

That doesn't mean we need to break things.  Ideally, we don't.  But if the
entire burden of making everything work exactly the way it always has is
put solely on the people who are trying to do something that excites them,
the stability that we will get will be the stability of death.

I do not believe people working on Debian want to break other people's use
cases for the fun of it.  However, enthusiasm is fragile.  Please, try to
engage with people, find creative solutions, and try to preserve the
things they're excited about in their projects, rather than muffling them
in layers of obstructionism.  We need excited people and enthusiastic
people to make Debian something we can all be proud of.

-- 
Russ Allbery (r...@debian.org)   

Re: support for merged /usr in Debian

[Nikolaus Rath]

On Jan 08 2016, Tobias Frost  wrote:
> Am Freitag, den 08.01.2016, 09:14 -0800 schrieb Nikolaus Rath:
>>  Debian is developed by its developers, not by its users. Do you have
>> any evidence (other than your opinion) that loss of users would cause
>> loss of development work?
>
>
> Our priorities are our users and free software
>
> We will be guided by the needs of our users and the free software
[...]

I don't see how this answers my question (unless you are agreeing with
me). Almost every Debian developer is a Debian user.

Best,
-Nikolaus

(No Cc on replies please, I'm reading the list)
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: support for merged /usr in Debian

[Robert Edmonds]

Simon McVittie wrote:
> 0m24.5s DEBUG: Starting command: ['adequate', '--root',
> '/srv/piuparts.debian.org/tmp/tmpk5ZNdX', 'iputils-ping']
> 0m24.6s DUMP:
>   iputils-ping: bin-or-sbin-binary-requires-usr-lib-library /bin/ping6
> => /usr/lib/x86_64-linux-gnu/libgnutls-openssl.so.27
> 
> I don't know why a ping implementation wants to do SSL, but let's assume
> that's a useful thing to do for some reason. Are you saying that GNUTLS
> and all its dependencies should move from /usr to /?

Looks like it's not actually SSL that ping6 wants to do, but MD5, due to
the support for "ICMPv6 Node Information Queries (RFC4620)":

https://tools.ietf.org/html/rfc4620#section-5

[...] Compute the MD5 hash [...]

If it really does need to do MD5, maybe it could use the one in libbsd0
instead of dragging in libgnutls-openssl27 and its dependencies.

-- 
Robert Edmonds
edmo...@debian.org

Re: support for merged /usr in Debian

[Svante Signell]

On Fri, 2016-01-08 at 19:15 +0100, Marc Haber wrote:

> Quite some developers are getting paid to be Debian users or by
> Debian
> users. We participate in Debian because it makes using Debian easier
> for the people who pay us.On Fri, 08 Jan 2016 09:14:45 -0800,
> Nikolaus Rath 
> 
> 
> If these users stop being Debian users, they have no reason to pay
> developers to make Debian better. This causes significant loss of
> development work.
> 
> Not all Debian contributors are contributing because they're students
> that need to get rid of free time. And, in fact, contributing to
> Debian has significantly lost being fun over the last five years.
> 
> Alas, maybe I'm just too old.

No you are not. Debian following the commercial vendor track will make
them extinguished. Technically there are no real advantages of the new
(in many youngsters mind revolutionary) ideas. The idea of a Debian
Universal Operating System, supporting Free Software (not Open Source
Software), is dead.

Re: support for merged /usr in Debian

[Svante Signell]

On Fri, 2016-01-08 at 09:14 -0800, Nikolaus Rath wrote:
> On Jan 08 2016, Svante Signell  wrote:

> > The problem is that with Debian heading down this road, the Debian
> > GNU/Linux distribution will not exist in 5 years from now.
> 
> Debian is developed by its developers, not by its users. Do you have
> any evidence (other than your opinion) that loss of users would cause
> loss of development work?

That would be the biggest mistake ever made in Debian history. What
would you do with a distribution having no users?

Re: support for merged /usr in Debian

[Tobias Frost]

Am Freitag, den 08.01.2016, 09:14 -0800 schrieb Nikolaus Rath:
> 
> Debian is developed by its developers, not by its users. Do you have
> any
> evidence (other than your opinion) that loss of users would cause
> loss
> of development work?


Our priorities are our users and free software

We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environments. We will not object to non-free works
that are intended to be used on Debian systems, or attempt to charge a
fee to people who create or use such works. We will allow others to
create distributions containing both the Debian system and other works,
without any fee from us. In furtherance of these goals, we will provide
an integrated system of high-quality materials with no legal
restrictions that would prevent such uses of the system.

(Our social contract)

md5(3bsd) (was: Re: support for merged /usr in Debian)

[Marco d'Itri]

On Jan 08, Robert Edmonds  wrote:

> If it really does need to do MD5, maybe it could use the one in libbsd0
> instead of dragging in libgnutls-openssl27 and its dependencies.
I did not notice this recent addition...
Folks, there is *a lot* of software which embeds copies of md5.c: please 
try to convert it to use libbsd!
And how many of you still have copies of setproctitle.c around? Do you 
know that they probably come from sendmail? Clean up your old code!

If you have some old package with plain makefiles which needs to be 
converted to use libbsd then you can have a look at my openbsd-inetd 
package for inspiration.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 08 Jan 2016 09:14:45 -0800, Nikolaus Rath 
wrote:
>On Jan 08 2016, Svante Signell  wrote:
>> The problem is that with Debian heading down this road, the Debian GNU/Linux
>> distribution will not exist in 5 years from now.
>
>Debian is developed by its developers, not by its users. Do you have any
>evidence (other than your opinion) that loss of users would cause loss
>of development work?

Quite some developers are getting paid to be Debian users or by Debian
users. We participate in Debian because it makes using Debian easier
for the people who pay us.

If these users stop being Debian users, they have no reason to pay
developers to make Debian better. This causes significant loss of
development work.

Not all Debian contributors are contributing because they're students
that need to get rid of free time. And, in fact, contributing to
Debian has significantly lost being fun over the last five years.

Alas, maybe I'm just too old.

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

Re: support for merged /usr in Debian

[Michael Prokop]

* Stephan Seitz [Fri Jan 08, 2016 at 11:18:41AM +0100]:
> On Fri, Jan 08, 2016 at 10:11:07AM +, Jonathan Dowland wrote:
> >grml is packaged and is an apt-get away. It's third-party in just the
> >same way that the linux kernel, or exim are.

> Wrong. You have a wrapper package that adds grml iso from /boot/grml
> to the grub.cfg. You have to download the grml images yourself and
> you need the space to save the images in /boot/grml.

We've an open wishlist bug report for the "download the Grml ISO"
part (#754393) which we plan to resolve soonish, jfyi.

regards,
-mika-


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Ian Campbell]

On Fri, 2016-01-08 at 10:11 +, Jonathan Dowland wrote:
> On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote:
> > The upside of this is that this will free up space in / which will be
> > needed for a dedicated recovery image. Too bad that we don't have such
> > a thing ourselves and have to recommend third-party products like grml
> 
> grml is packaged and is an apt-get away. It's third-party in just the
> same way that the linux kernel, or exim are.

What is the package called? By coincidence I was looking for it the other
day and all I found was:

$ apt-cache search grml
grml-debootstrap - wrapper around debootstrap for installing pure Debian
grml-rescueboot - Integrates Grml ISO booting into GRUB
grml2usb - install Grml system / ISO to usb device

The first and last are not relevant and AFAICT the middle one is support
for creating grub entries from files in /boot/grml which appear to get
there by some out of band means (i.e. by hand AFAICT). The
Depends/Recommends/Suggests of that package don't mention any other package
which might provide the actual download.

Ian.

Re: support for merged /usr in Debian

[Michael Prokop]

* Ian Campbell [Fri Jan 08, 2016 at 10:22:01AM +]:
> On Fri, 2016-01-08 at 10:11 +, Jonathan Dowland wrote:
> > On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote:

> > > The upside of this is that this will free up space in / which will be
> > > needed for a dedicated recovery image. Too bad that we don't have such
> > > a thing ourselves and have to recommend third-party products like grml

> > grml is packaged and is an apt-get away. It's third-party in just the
> > same way that the linux kernel, or exim are.

> What is the package called? By coincidence I was looking for it the other
> day and all I found was:

> $ apt-cache search grml
> grml-debootstrap - wrapper around debootstrap for installing pure Debian
> grml-rescueboot - Integrates Grml ISO booting into GRUB
> grml2usb - install Grml system / ISO to usb device

The grml-rescueboot package is the one which is meant here.

> The first and last are not relevant and AFAICT the middle one is support
> for creating grub entries from files in /boot/grml which appear to get
> there by some out of band means (i.e. by hand AFAICT). The
> Depends/Recommends/Suggests of that package don't mention any other package
> which might provide the actual download.

Exactly.

Once #754393 has been resolved the download of the ISO straight to
/boot/grml should be trivial. I'm even considering providing
packages named like grml-rescueboot-grml64-small which just execute
the said script with according parameters inside their postinst - so
once you install grml-rescueboot-grml64-small the ISO is put
automatically in place for you. (I highly appreciate any feedback,
further wishes, approaches + ideas regarding that.)

regards,
-mika-


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Lars Wirzenius]

On Fri, Jan 08, 2016 at 01:31:12PM -0800, Russ Allbery wrote:
> What will kill Debian faster than anything else is to have every idea for
> changing something large, interesting, or possibly revolutionary in Debian
> be met with anger, derision, and attacks.

Hear, hear. I snipped out the rest of Russ's mail, but only for
brevity: I fully agree with all of it. Extremely well said, Russ.

I feel that there is fair bit of unresolved conflict sloshing around
the project. This happens when people have a disagreement, and it's
not handled properly on an emotional level: even though the
disagreement is resolved on a technical level, and a decision is made
and implemented, those who didn't agree with it don't get proper
emotional closure, they feel put upon and rejected, that their
concerns do not matter. It's like they are wounded, and the wound
never gets to heal, and if there's any future disagreement, the old
wound gets torn open again. That's not healthy.

In the Battlestar Galactica remake, they have a fleet-wide boxing
match, where anyone can challenge anyone regardless of rank, and they
hit each other and this somehow gives emotional closure. I do not
suggest this, since violence really isn't an answer, and even if it
were, losing a boxing match as well as an argument isn't going to give
closure. Resolving conflicts by having new conflicts isn't the
solution.

What could we do instead, to prevent and to handle these things?

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Tue, 5 Jan 2016 02:07:35 +0100, Christian Seiler
 wrote:
>On 01/05/2016 01:34 AM, Marc Haber wrote:
>> On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop 
>> wrote:
>>> On 2016-01-04 12:03:07, Marc Haber wrote:
 On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote:
> Anyway, if you think that the merged /usr scheme is about systemd then 
> you are automatically disqualified from taking part in this discussion 
> because you are not understanding the basic underlying issues.

 As friendly as always.
>>>
>>> Friendly? Maybe not. But correct? Yes.
>> 
>> Being right and unfriendly drives friends and users away. This
>> attitude is doing harm to Debian.
>
>Marco started this thread because he wanted to discuss a specific
>proposal - merging /bin, /lib and /sbin into /usr.

And people happen to disagree.

>But _after_ this thread, where lots of people have patiently tried to
>explain the issues again and again, and even tried to find ways of
>constructively coming to a compromise - don't you think that repeating
>the same talking points again in this very same thread instead of
>actually responding to the issues presented, don't you think that
>that is far more harmful to Debian than a single comment borne out
>of frustration?

The problem is not the single comment, which I meant with "as always".

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

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote:
> The upside of this is that this will free up space in / which will be
> needed for a dedicated recovery image. Too bad that we don't have such
> a thing ourselves and have to recommend third-party products like grml

grml is packaged and is an apt-get away. It's third-party in just the
same way that the linux kernel, or exim are.

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 08:16:06AM +0100, Svante Signell wrote:
> The problem is that with Debian heading down this road, the Debian GNU/Linux
> distribution will not exist in 5 years from now. You will make yourselves
> extinct due to the competition from commercial alternatives.

You greatly overestimate Debian's capacity to do anything quickly, including
dying.

Re: support for merged /usr in Debian

[Stephan Seitz]

On Fri, Jan 08, 2016 at 10:11:07AM +, Jonathan Dowland wrote:

grml is packaged and is an apt-get away. It's third-party in just the
same way that the linux kernel, or exim are.


Wrong. You have a wrapper package that adds grml iso from /boot/grml to 
the grub.cfg. You have to download the grml images yourself and you need 
the space to save the images in /boot/grml.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: support for merged /usr in Debian

[Marc Haber]

On Mon, 4 Jan 2016 14:15:21 +0100, Christian Seiler
 wrote:
>On 01/04/2016 11:44 AM, Marc Haber wrote:
>> On Sun, 3 Jan 2016 21:35:39 +0100, Christian Seiler
>>  wrote:
>>> So that was the state in February of 2011, when the warning was added
>>> to systemd and the systemd developers recommended the use of the
>>> initrd: mounting /usr from a running system is broken. Either it is
>>> already completely broken in some cases - and for all other cases where
>>> it currently works it is broken maintenance-wise.
>> 
>> Declaring something that was the normal use case five years ago as
>> broken is a blatant sign of disrespect for users.
>
>Ok, so when Wheezy came around, 5 years before that a normal use case
>for init scripts was to have a fixed start/stop priority that was used
>when calling update-rc.d - and in Wheezy (this was pre-systemd!) the
>update-rc.d implementation completely ignores the start/stop priorities
>and says it only does dependency-based boot now (it shows a warning if
>priorities are still specified). Is that also a blatant sign of
>disrespect for users?

No, this change was largely painless. I had only systems with badly
maintained third-party packages break.

>With your argumentation you could argue that ANY
>change is a blatant disrespect for users.

No, this is only the case for really intrusive changes that noone had
asked for.

>I'm really curious: what's your solution?

Keep support for things that used to work for, say, at least three or
four stable releases, document that and commit to it. And, of course,
stick to it.

That way, a local admin can change installation to adapt to new ways
and to necessary migrations of existing systems on _her_ schedule.
Forcing intrusive and time-consuming changes with a single stable
release is bad bad bad.

>Diagnosis: mounting /usr from / doesn't work properly

It works fine for the vast majority of setups, including LVM and
crypted file systems. It breaks for important corner cases such as
having /usr on storage media that needs exotic drivers or the network.
I'd hardly call that "broken".

>Now what do do about it? You seem to be suggesting that people should
>try to maintain the current state of affairs regardless. There's ample
>evidence that that simply won't work.

I don't see this evidence as compelling as you do.

>Suggestion by other people: ok, so we still want to support a separate
>/usr partition, so what do we do now? Oh yes, we just mount it already
>in the initrd, because that already has support for mounting
>filesystems (such as the root filesystem). Now people can still have
>their separate partitions but we don't have to support the use case of
>mounting /usr from / anymore.

That's not nice, but fine and acceptable _IF_ there is commitment to
keep things this way. There are significant changes to the initrd on
the horizon, and those changes involve switching to a software with an
upstream that has a reputation about not giving a damn about existing
systems because they have been broken and maintained the wrong way all
time before and declaring having no hooks as design feature.

>Plus: if we do that, we get a exciting possibilities, because we can
>just put everything in /usr, which is what the UsrMerge is all about,
>so we can actually make lemonade from those lemons.

What about if I prefer something that tastes like oranges? Do I have
to change to lemonade when the release team pushes the button? An
Universal Operating System should not declare oranges as "obsolete"
just because lemons do have more vitamin C.

>Response: well, in some cases a full-blown initrd is not an option. I
>respond in this thread with providing a 300 LoC PoC for a minimalistic
>initrd that's *reall* small. I ask people who have been complaining
>here whether this would address their concerns. What do I get? Silence.

I appreciate that effort, but for me it misses the point. I have
always been using initramfs, initramfs-tools do a splendid job, and as
long as this functionality is preserved and Debian commits to this I
am just fine with a /usr merge stretched about a few releases. This is
nothing we have to force for stretch or buster.

>So really, what would you suggest? How would you solve this issue?

Documentation and commitment.

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

Re: support for merged /usr in Debian

[Brian May]

Marc Haber  writes:

> Keep support for things that used to work for, say, at least three or
> four stable releases, document that and commit to it. And, of course,
> stick to it.

So at approx 2 years per stable release, that would be around 6 to 8
years before we could get this optional change into Debian. Which in
turn mean we are 6 to 8 years behind the other major Linux
distributors. That would definitely put me off Debian.

Or maybe you can see into the future, and can see a time when the new
/usr will be mandatory for all users. Maybe this is your concern. You
want a commitment for it to remain optional for at least 6 to 8 years.

Do we want debian to be slow and conservative or fast and bleeding edge?

I would find 6 to 8 years far too long myself, by the time we get
changes in a stable release, it is likely they will already be obsolete
and replaced by something better. It would probably result in Debian
being forked by people who want to develop using the latest standards
but unable to do so in Debian.

Maybe what you are looking for is LTS support or extended LTS support on
our releases?
-- 
Brian May 

Re: support for merged /usr in Debian

[Riku Voipio]

On Fri, Jan 08, 2016 at 09:50:56AM +0100, Marc Haber wrote:
> The loss of keyscript just broke my clients. I am really afraid of the
> first system update breaking my _servers_, causing a resinstall to be
> necessary. I know of one customer who already said that if a reinstall
> will become necessary, the reinstalled distribution will be called Red
> Hat Enterprise Linux. I'd like to postpone this as long as possible.

If bug-free upgrades are valueble for you and your clients, it doesn't
seem wise to bet on luck that nothing will break. Debian has had
quite good record on successful in-place upgrades, but it mostly depends
on volunteers doing manual dist-upgrade tests during freeze. Which is often
too late and too little.

Settings up automated upgrade tests at jenkins.debian.net for both generic
installs and installs similar your setup would let you identify and fix
issues before they become problems in your production. 

Riku

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 13:04:16 +, Riku Voipio 
wrote:
>On Fri, Jan 08, 2016 at 09:50:56AM +0100, Marc Haber wrote:
>> The loss of keyscript just broke my clients. I am really afraid of the
>> first system update breaking my _servers_, causing a resinstall to be
>> necessary. I know of one customer who already said that if a reinstall
>> will become necessary, the reinstalled distribution will be called Red
>> Hat Enterprise Linux. I'd like to postpone this as long as possible.
>
>If bug-free upgrades are valueble for you and your clients, it doesn't
>seem wise to bet on luck that nothing will break. Debian has had
>quite good record on successful in-place upgrades, but it mostly depends
>on volunteers doing manual dist-upgrade tests during freeze. Which is often
>too late and too little.

All _my_ clients run unstable anyway, and it only really broke the
test system. It just ate a few days of tinkering at an inconvenient
time to get the test system to boot again and to upgrade the other
machines in the process.

>Settings up automated upgrade tests at jenkins.debian.net for both generic
>installs and installs similar your setup would let you identify and fix
>issues before they become problems in your production. 

I am doing this. I still hate the idea that my test systems break as
this means work and danger in production.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 14:24:52 +0100, Christian Seiler
 wrote:
> - Instead it was proposed to use password agents (see [1]) for this.
>
> - Problem with that is that the password agents don't support
>   arbitrary binary data, which is needed for keys (they only support
>   plain text).

And there is no example code for a password agent aside of some proof
of concept code in python (which is not recommended to use in
production) and the whole concept breaks if the unlocking scheme for
filesystem A involves unlocking filesystem B because it has part of
the key.

This is not a replacement for keyscripts, it is a triangle instead of
a wheel.

>As far as I can tell, this is a case where upstream's goal of creating
>the best technical solution for a problem gets in the way of having
>something that works at all.

Amen.

>and the reason why this didn't
>affect Jessie much worse is that initramfs-tools still support
>keyscript=, so unlocking the rootfs still works via this mechanism.

Which leaves the issue of unlocking the other filesystems that need
unlocking for the system to run. I have resorted to unlocking
everything I need in the initramfs, which had the result of making
initramfs more complex, not easier. Well done, systemd.

>And it'd be one thing if a proper solution had been around the corner
>and this feature had been missing for a couple of months, but it has
>been years, and there is no perspective on when a patch for this would
>be accepted upstream, because (from what I read on the mailing list)
>they appear to want to have early-boot IPC before touching the
>password agent code again - which means it could take another 2 or 3
>years.

*sigh*

>And yes, I get why what has been proposed upstream is better in the
>long term,

I don't. It introduces thousands of lines of code of complexity in
early boot which already is hard enough to debug.

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

Re: support for merged /usr in Debian

[Niels Thykier]

Riku Voipio:
> On Fri, Jan 08, 2016 at 09:50:56AM +0100, Marc Haber wrote:
>> The loss of keyscript just broke my clients. I am really afraid of the
>> first system update breaking my _servers_, causing a resinstall to be
>> necessary. I know of one customer who already said that if a reinstall
>> will become necessary, the reinstalled distribution will be called Red
>> Hat Enterprise Linux. I'd like to postpone this as long as possible.
> 
> If bug-free upgrades are valueble for you and your clients, it doesn't
> seem wise to bet on luck that nothing will break. Debian has had
> quite good record on successful in-place upgrades, but it mostly depends
> on volunteers doing manual dist-upgrade tests during freeze. Which is often
> too late and too little.
> 
> Settings up automated upgrade tests at jenkins.debian.net for both generic
> installs and installs similar your setup would let you identify and fix
> issues before they become problems in your production. 
> 
> Riku
> 

Just adding a data point to the discussion:

 * Every single release breaks something[1][2][3][4].
 * Stretch is of course no exception[5].

Releases are not a question of "if" but rather "what" breaks (and "to
which extend"/"how many use-cases").

Note, if any one is concerned with Jessie's list of issues being longer
than Wheezy's list.  That is more likely to be a result from us putting
more effort into documenting issues for Jessie compared to Wheezy.
  Of course, I only have a "gut feeling" backing my claim.  Please do
not take it as a fact (nor as a disapproval of the efforts for Wheezy).

Thanks,
~Niels

[1]
https://www.debian.org/releases/etch/amd64/release-notes/ch-information.en.html

[2]
https://www.debian.org/releases/squeeze/amd64/release-notes/ch-information.en.html

[3]
https://www.debian.org/releases/wheezy/amd64/release-notes/ch-information.en.html

[4]
https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html

[5]
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html





signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Stephan Seitz]

On Fri, Jan 08, 2016 at 11:49:48AM +0100, Michael Prokop wrote:

We've an open wishlist bug report for the "download the Grml ISO"
part (#754393) which we plan to resolve soonish, jfyi.


Ah, thank you very much. That still leaves the space problem. Only my 
newer systems where I knew that I wanted to have grml in /boot are having 
enough space.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 09:44:17 +0100, Christian Seiler
 wrote:
>On 01/08/2016 09:41 AM, Marc Haber wrote:
>> On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
>> wrote:
>>> On 2016-01-04 11:30, Marc Haber wrote:
 On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
 wrote:
> System admins do like using absolute path
> for security reasons...
 Please also notice that this is the only option for ExecStart in
 systemd units. Well played, Lennart.
>>>
>>> Similarly skeleton-based init scripts use the full path as well. It 
>>> helps if you can stat() it. Which, I guess, you could by extension by 
>>> using "which" and the like.
>> 
>> In init scripts, I can do that. In a systemd unit, I cannot.
>
>ExecStart=/bin/sh -c "something"

This brings an ugliness including quoting hell to systemd units that I
would rather not have. You missed to quote this.

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

Re: support for merged /usr in Debian

[Marco d'Itri]

On Jan 08, Marc Haber  wrote:

> important functionality maked as "broken", "obsolete" and eventually
> removed, just as the keyscript= feature of /etc/crypttab was lost a
> year ago (noone cared).
Let's be clear here: nobody cared enough to implement it.
It was clearly explained by the upstream maintainers, multiple times, 
that they would have liked to have this feature.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 12:53:43 +0100, m...@linux.it (Marco d'Itri) wrote:
>On Jan 08, Marc Haber  wrote:
>> important functionality maked as "broken", "obsolete" and eventually
>> removed, just as the keyscript= feature of /etc/crypttab was lost a
>> year ago (noone cared).
>Let's be clear here: nobody cared enough to implement it.
>It was clearly explained by the upstream maintainers, multiple times, 
>that they would have liked to have this feature.

Citation please. I remembered getting something along the lines "this
is a Debianism, we don't care" as an answer. With a point, keyscript
_IS_ (resp was) a Debianism.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 08 Jan 2016 21:20:21 +1100, Brian May  wrote:
>Marc Haber  writes:
>> Keep support for things that used to work for, say, at least three or
>> four stable releases, document that and commit to it. And, of course,
>> stick to it.
>
>So at approx 2 years per stable release, that would be around 6 to 8
>years before we could get this optional change into Debian.

No, you can opt to change right now. Just don't force others to do it.

>Or maybe you can see into the future, and can see a time when the new
>/usr will be mandatory for all users. Maybe this is your concern. You
>want a commitment for it to remain optional for at least 6 to 8 years.

yes.

>Do we want debian to be slow and conservative or fast and bleeding edge?

Conservative enough to stay useable for professional IT operations. At
last this is what I want Debian to be. We are already losing behind
the Enterprise Distributions because they look on paper as if one can
install and forget for ten years.

>I would find 6 to 8 years far too long myself, by the time we get
>changes in a stable release, it is likely they will already be obsolete
>and replaced by something better. It would probably result in Debian
>being forked by people who want to develop using the latest standards
>but unable to do so in Debian.

Debian has already been forked by people who found Debian's release
cycles too long. The result is called Ubuntu, and we lost many of the
users (and developers!) who want shorter release cycles to them.

Now, we aim for shorter release cycles ourselves, which won't bring
any of the users back we lost to Ubuntu. But it'll make us now lose
the users that think we release too often to the Enterprise Linuxes.

That's what happens when one blindly follows users' wishes while
neglecting old values.

>Maybe what you are looking for is LTS support or extended LTS support on
>our releases?

Maybe. Having this is also blindly doing what others do while we did
so fine in the past.

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

Re: support for merged /usr in Debian

[Christian Seiler]

On 01/08/2016 12:53 PM, Marco d'Itri wrote:
> On Jan 08, Marc Haber  wrote:
> 
>> important functionality maked as "broken", "obsolete" and eventually
>> removed, just as the keyscript= feature of /etc/crypttab was lost a
>> year ago (noone cared).
> Let's be clear here: nobody cared enough to implement it.
> It was clearly explained by the upstream maintainers, multiple times, 
> that they would have liked to have this feature.

That's not really accurate. To make a long story *really* short:

 - Synchronous calls to an arbitrary executable is not something the
   systemd developers want to have in their code (see the linked
   posting). See e.g. [1], [2]

 - Instead it was proposed to use password agents (see [1]) for this.

 - Problem with that is that the password agents don't support
   arbitrary binary data, which is needed for keys (they only support
   plain text).

 - A patch for augmenting the password agent protocol to support
   binary data was rejected [3], with the idea that it would probably
   be better to use the kernel keyring instead of userspace to
   transmit these types of keys. Also, there have been strong hints
   (see e.g. [3], but also others that I can't find) that changing
   this would also require some early-available dbus, in form of
   kdbus, once that was done.

 - kdbus is not going to be here anytime soon.

So people actually did implement this and when the implementation was
available, the goal posts were moved by upstream.

As far as I can tell, this is a case where upstream's goal of creating
the best technical solution for a problem gets in the way of having
something that works at all.

The main problem is that there isn't any good way of getting a binary
key into systemd's cryptsetup implementation at all - so that it's
currently not possible to use anything other than passwords or
key files if one wants to use systemd-cryptsetup. This breaks a lot of
other use cases, such as two-factor authentication, using the TPM,
using external key hardware, etc. - and the reason why this didn't
affect Jessie much worse is that initramfs-tools still support
keyscript=, so unlocking the rootfs still works via this mechanism.

And it'd be one thing if a proper solution had been around the corner
and this feature had been missing for a couple of months, but it has
been years, and there is no perspective on when a patch for this would
be accepted upstream, because (from what I read on the mailing list)
they appear to want to have early-boot IPC before touching the
password agent code again - which means it could take another 2 or 3
years.

And yes, I get why what has been proposed upstream is better in the
long term, and if I had such a use case I personally wouldn't care
about what technical solution is used in the background (whether
keyscript or something else), and I wouldn't complain if I had to
change things on upgrade because of some new solution, but if I look
at the time scales involved, it seems very unreasonable to me to say
"in a couple of years your use case will be supported again" - and I
think that breaking very legitimate use cases without a sensible
recourse would be reason enough to say "well, let's support it at
least until we have a better solution available".

Regards,
Christian

[1] http://lists.freedesktop.org/archives/systemd-devel/2012-July/005835.html
[2] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031173.html
[3] http://lists.freedesktop.org/archives/systemd-devel/2014-July/020880.html



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 10:32:03 +0100, Andrew Shadura 
wrote:
>Marc, please re-read the whole thread from the very beginning. Nobody
>forces merged /usr on you.

Enough trust has been lost in the past years that I'd like to have a
commitment for that. Write it down, and I'm fine.

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

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 03:13:12PM +0100, Marc Haber wrote:
> All _my_ clients run unstable anyway

I'll leave the obvious response here to others.

But, what I find odd about this is you've suggested that there should be a
*multi-release* transition for a change like this, more than once in the
thread. Asking volunteers to coordinate a change over an unknown and unknowable
period of time (but that could feasibly be a decade!) is unreasonable IMHO,
and since you are running sid anyway, it wouldn't even help you, so I'm puzzled
why you suggested it.

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 11:18:41AM +0100, Stephan Seitz wrote:
> Wrong. You have a wrapper package that adds grml iso from /boot/grml to the
> grub.cfg. You have to download the grml images yourself and you need the
> space to save the images in /boot/grml.

Thanks for explaining: I was under the mistaken impression that the ISO was
packaged too.

> Shade and sweet water!

This (still) should go *below* your sig separator.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

Re: support for merged /usr in Debian

[Niels Thykier]

Marc Haber:
> Debian has already been forked by people who found Debian's release
> cycles too long. The result is called Ubuntu, and we lost many of the
> users (and developers!) who want shorter release cycles to them.
> 
> Now, we aim for shorter release cycles ourselves, which won't bring
> any of the users back we lost to Ubuntu. But it'll make us now lose
> the users that think we release too often to the Enterprise Linuxes.

Hi,

We have generally released every 2nd year for the past 3-4 releases, if
not more.  The release cycle will /probably/ also be around two years.

What a lot of people have desired is a shorter *freeze* - as in spending
less time frozen and more time developing.  Given the latter half of our
freeze tends to involve mostly frustration, fragmentation of developers
and very few bug fixes, I am personally one of the people, who would
like to see Debian have shorter freezes[1].

Thanks,
~Niels

[1] Notably by having fewer bugs that need to be fixed /when/ we freeze.






signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 15:01:53 +, Jonathan Dowland 
wrote:
>and since you are running sid anyway, it wouldn't even help you, so I'm puzzled
>why you suggested it.

You obviously don't see the difference between a customer, a client
machine and a server. This might be a matter of language, so I'll
explain it.

A customer is a company paying me to do things. This usually includes
building and/or running some services on Linux for them. Once upon a
time, this used to be 100 % Debian, but since Debian has started
shortening their release periods, two years later began freezing
distributions two days after changing the default init system to
something entirely different, resulting in a somewhat half-baked, but
surprisingly painless stable release, Enterprise Linuxes have begun to
take on share massively, much to my dismay.

A client is a system that has a human between chair and keyboard. This
includes notebooks and desktop PCs and is usually running Windows,
especially for technically uninterested people. "My" clients are a
small number, exactly three of them. One production notebook, a
desktop, and a secondary notebook for testing and reference purposes.
At least one of the notebooks needs to work at any time, and since I
am a DD, those are running Debian unstable. They do break from time to
time, sometimes due to software errors, sometimes due to surprising
changes to software (such as, no keyscript handling any more). Since
especially the notebooks are only updated when the other one is (a)
near and (b) working, one of them breaking is expected and not a big
problem.

A server is a system I get paid to keep it running. It usually doesn't
have chair, keyboard or screen, is either virtualized or stacked awary
in a datacenter that I have not even seen in most cases, and runs
Debian stable. Break one of them, and I am in trouble either way.
Those machines are those I worry about.

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

Re: support for merged /usr in Debian

[Christian Seiler]

On 01/08/2016 10:21 AM, Marc Haber wrote:
> On Mon, 4 Jan 2016 13:38:15 +0100, Christian Seiler
>  wrote:
>> On 01/04/2016 11:41 AM, Marc Haber wrote:
>>> We have already shown how "much" we care about the users of non-Linux
>>> kernels in Debian ("not at all, they can happily go fishing").
>>
>> So why aren't you on the list of porters for either Hurd of kFreeBSD?
> 
> Since when does one have to actually work on something to be allowed
> to find it important and interesting.

I'm apologize, I was being a bit too snarky here. I just had a lot of
experience with many people that don't care about non-Linux ports at
all (as evidenced by their other actions) but said things very similar
to what you said in order to complain louder. While that may not be
accurate in your case (again: sorry), I am a bit frustrated with that
type of comment when it comes from people who don't actually work on
those ports.

>> Sorry, but this is bogus, because this is a problem you have on every
>> every upgrade. In the past I've already had to repartition systems
>> because / had become too small, because the amount of software required
>> to be there had grown (to support more storage solutions for mounting
>> /usr) and also the kernel modules had grown.
> 
> If hundreds of megabytes of software would get moved from /usr to /,
> this would certainly overflow my root file systems.

That is not what is going to happen. Nobody ever proposed that. I
don't know where people constantly get this idea...

> In fact, as I have
> understood things, software will move from / to /usr,

Exactly, this is what is proposed.

> making the
> system completely unuseable if the multi-gigabytes /usr does not mount
> for some reason.

The system could also be unusable if / doesn't mount, or the kernel
image is damaged, or...

Note that on a typical system writes to / are more likely than writes
to /usr (usually only APT/dpkg writes to /usr), so one could argue
that /usr is typically a bit safer from corruption because it
experiences less writes than /.

 => In that scenario, with /usr being OK but / being corrupted,
UsrMerge would improve changes of having a bootable system.
(You don't necessarily need an intact /etc/fstab here, btw.,
since there are standards for how to auto-detect the /usr
partition according to the GPT partition type, if you use
that. Don't know what Debian's current support of that is,
but the idea exists in principle.)

Failure cases happen. Different file system layouts will have different
consequences for these - but there always will be some things better
and other things worse depending on what kind of failure you have with
which kind of configuration. So I don't think it's as clear-cut as you
may think it is when it comes to recovery.

>> [Repartitioning due to updates]
> 
> Yes, this happens. Do we really have to _force_ this? It is annoying
> enough when it happens caused by the normal flow of things. Even if
> this is the case, not all systems will explode during the same system
> upgrades, allowing the local admin to spread those changes over two or
> even three releases. If we would, in some future, ship an upgrade that
> uncaringly would _require_ a repartitioning, this spread would not be
> possible, and it would undoubtedly call up management attention, which
> could in turn lead to management taking vendor decisions that we don't
> want.

Well, but that can go both ways:

1. /usr is too small, then UsrMerge will require repartitioning
2. / is too small to handle the additional binaries that were added
   to / during the next release, then UsrMerge would prevent
   repartitioning, which you'd have to do without it

So also here it's not clear to me whether it will require more or
less repartitioning. Could go either way.

>>> And, I really don't want to have to adapt, test and verify scripts and
>>> backup schemes to changed partition layout. This will be necessary for
>>> new systems, and it is really a horror vision to have to do this for
>>> existing systems during upgrades.
>>
>> You will always have to adapt things to upgrades, because lots of small
>> details can change.
> 
> That does not mean that we're entitled to needlessly add a big detail
> that changes.

In some sense it's a big change, in some sense it's not. For most
software, it will be absolutely trivial, because the programs will
all still be available.

> [Potential problems with the backup]

I don't get your remarks:

If you back up every file system with --one-file-system separately,
(as you appear to be doing) other than the relative sizes of the
backups (the /usr part is going to be larger, the / part smaller by
the same amount) nothing at all should change.

> And I need
> to change documentation, which will probably trigger a review process
> with management attention.

This may be very unfortunate for you, but I don't think a
situation like yours should be the basis for deciding distribution

Re: support for merged /usr in Debian

[Nikolaus Rath]

On Jan 08 2016, Svante Signell  wrote:
> On Thu, 2016-01-07 at 22:46 +0100, Philip Hands wrote:
>> Marc Haber  writes:
>> 
>> > On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri  wrote:
>> > > On Jan 05, Ian Jackson  wrote:
>> > > 
>> > > > People who have been using a configuration for many years naturally
>> > > > become upset when they are told that it has been `unsupported' for all
>> > > > of this time and that, implicitly, changes are going to be made which
>> > > > will break it.
>> > > I think that your summary is correct, and I am quite sure that it would 
>> > > be a bad engineering practice to make technical decisions based on 
>> > > people's emotions.
>> > 
>> > Unfortunately, it's emotions that take vendor decisions. Your attitude
>> > is driving big users towards the paid-for Enterprise Linuxes, be it
>> > logical or not, be it good engineering or not.
>> 
>> Even if that were true, I fail to understand why we should be worried.
>
> The problem is that with Debian heading down this road, the Debian GNU/Linux
> distribution will not exist in 5 years from now.

Debian is developed by its developers, not by its users. Do you have any
evidence (other than your opinion) that loss of users would cause loss
of development work?


Best,
-Nikolaus

(No Cc on replies please, I'm reading the list)
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: support for merged /usr in Debian

[Simon McVittie]

On 07/01/16 08:36, Paul Wise wrote:
> $something should
> automatically manage the contents of /bin /sbin /lib (/boot?) based on
> the tools needed to mount /usr (perhaps plus some more recovery
> tools)

I really don't think that's a good approach, particularly as a default.
We already have tools to make a minimal bootable environment that can
mount /usr and do some limited recovery, and the result is called an
initramfs. If you want a lighter-weight initramfs for environments where
those generated by initramfs-tools or dracut are overkill, Christian
Seiler has a nice proof-of-concept elsewhere in the thread, which
apparently compiles to less than 16K.

If you're using binaries in /usr and copying a dependency-closure subset
of them to the root filesystem, what makes that any better than using
binaries in /usr and copying a dependency-closure subset of them into
the initramfs? You basically end up doing a 2-phase boot (mount /usr,
then start the parallelizable part of the boot process) either way.

One key difference that I can see is that the initramfs has one job - it
mounts critical filesystems and is dropped from RAM - so any special
configuration that it needs doesn't interfere with normal operation. The
root filesystem (without /usr, if your /usr is separate) has two jobs:
it has to mount /usr, and it has to be the real root filesystem
afterwards. For instance, the tools in /bin and /sbin are reading the
same configuration in /etc, and system-integration glue in /etc or /lib,
that you use for the fully functional system, including arbitrary
/{etc,lib}/udev hooks (which might run helpers with long dependency
chains), arbitrary PAM modules, arbitrary NSS modules... all of which
you probably want, *later*, or you wouldn't have installed them, but not
before /usr comes up.

To make this plan work, you'd need to somehow make sure that all the
tools used between "start init" and "mount /usr" were running in a mode
where they avoided doing anything that couldn't be done before mounting
/usr. That sounds suspiciously like reinventing the initramfs, but with
the additional constraint that it has to work with the same /etc as the
fully-featured system.

If I absolutely had to implement your plan, I'd do it by writing a
minimal pid-1 which does the minimum necessary to mount /usr, then execs
the real init (sysvinit, systemd, whatever)... which, again, is sounding
suspiciously similar to an initramfs, in which the kernel executes a
script or binary (typically /init or /linuxrc) as pid 1, and that
process is expected to finish by exec'ing the real init.

If you're on an embedded platform where the bootloader doesn't
understand initramfs, it's entirely possible to embed a small initramfs
in the kernel image itself (AIUI, initramfs-capable kernels always have
one, but it's usually empty) - CONFIG_INITRAMFS_SOURCE is the option to
look for. Christian's 16K initramfs sounds ideal for that.

S

Re: support for merged /usr in Debian

[Russ Allbery]

Marc Haber  writes:

> Unfortunately, it's emotions that take vendor decisions. Your attitude
> is driving big users towards the paid-for Enterprise Linuxes, be it
> logical or not, be it good engineering or not.

...the ones that have already merged /usr and /?

I'm not sure I understand this reasoning.

-- 
Russ Allbery (r...@debian.org)   

Re: support for merged /usr in Debian

[Paul Wise]

While reading the LWN article about this, I had a thought that might
be interesting.

The packages should all install to /usr and $something should
automatically manage the contents of /bin /sbin /lib (/boot?) based on
the tools needed to mount /usr (perhaps plus some more recovery
tools), just like we do with initramfs-tools/dracut automatically
managing the contents of the initramfs based on the tools needed to
mount the /usr partition. However, as Simon suggests it may not be
feasible to automatically determine what the contents of /bin /sbin
/lib should be.

https://lwn.net/Articles/670071/
https://lists.debian.org/msgid-search/568ce53e.9020...@debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: support for merged /usr in Debian

[Marco d'Itri]

On Jan 08, Paul Wise  wrote:

> The idea was for those who don't want an initramfs or can't use an
> initramfs (someone mentioned some Debian platforms can't) but still
All platforms can use an initramfs.
It has been said that some have[citation needed] crappy boot loaders 
that do not support loading an initramfs, but you can still embed one in 
the kernel binary if you are building your own kernel anyway.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Paul Wise]

On Fri, Jan 8, 2016 at 7:16 AM, Simon McVittie wrote:

> I really don't think that's a good approach, particularly as a default.
> We already have tools to make a minimal bootable environment that can
> mount /usr and do some limited recovery, and the result is called an
> initramfs. If you want a lighter-weight initramfs for environments where
> those generated by initramfs-tools or dracut are overkill, Christian
> Seiler has a nice proof-of-concept elsewhere in the thread, which
> apparently compiles to less than 16K.

The idea was for those who don't want an initramfs or can't use an
initramfs (someone mentioned some Debian platforms can't) but still
want /usr on a separate partition. Essentially it is what the Unix
people should have done back in the day instead of hardcoding the
contents of /bin /sbin /lib.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: support for merged /usr in Debian

[Marc Haber]

On Wed, 6 Jan 2016 09:57:26 +, Jonathan Dowland 
wrote:
>On Fri, Jan 01, 2016 at 06:20:42PM +0800, Paul Wise wrote:
>> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>> 
>> > https://wiki.debian.org/UsrMerge
>> 
>> Now that we have union mounts in Linux
>
>Do you mean overlayfs? If so can you or anyone vouch for its quality?

I am using Overlayfs for mini-buildd and sbuild systems, overlaying an
ext4fs with an tmpfs for build chroots.

Works like a charm, so far.

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

Re: overlayfs (was: Re: support for merged /usr in Debian)

[Matthias Klumpp]

I am using overlayFS in Limba[1], and it works well (and is really
fast!) for read-only filesystems, read-write sometimes has issues if
you are using multiple OverlayFS layers (which made me adjust the code
so this doesn't happen anymore).

2016-01-06 17:29 GMT+01:00 Jonathan Dowland :
> I wish I could, but I can't, sorry. All I know is I got mysterious ENOENT
> errors at unpredictable times at some point in the layer stack when using
> it as a docker back-end and developing docker images. I can't recall what
> version of overlayfs/kernel I was using at the time; probably latest RHEL
> 7.* but I'm not sure.

Did you use Linux 4.2 and were maybe hit by this bug:
https://lkml.org/lkml/2015/10/7/289 ?

Cheers,
Matthias

[1]: https://packages.debian.org/sid/limba

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: support for merged /usr in Debian

[Marc Haber]

On Thu, 07 Jan 2016 14:48:56 -0800, Russ Allbery 
wrote:
>Marc Haber  writes:
>> Unfortunately, it's emotions that take vendor decisions. Your attitude
>> is driving big users towards the paid-for Enterprise Linuxes, be it
>> logical or not, be it good engineering or not.
>
>...the ones that have already merged /usr and /?

Yes. Those decisions are often taken for non-technical reasons, such
as availability or friendlyness of support and communities.

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