On Mo, 2021-06-07 at 12:35 -0400, Neal Gompa wrote:
On Mon, Jun 7, 2021 at 12:10 PM Martin Wilck
I for one would clean this up when I update one of my package in a
that I know won't go into SLE any more anyway, but no sooner.
But when is that? None of the rest of us peons get to know that.
I don't know either, yet :-) I was speaking with the package maintainer
hat on, not the SLE product strategy insider (which I am not).
In many ways, I think that restriction has made it
difficult for us
innovate because too many people have a SLE-first mentality to
Tumbleweed. Maybe this is a consequence of not having a regular
release anymore (I wasn't terribly involved during the time the
classic releases existed), but it's frustrating when things are
"stuck" because of SLE.
I can't speak for everyone, but "SLE first" doesn't nail it.
rather "let's not forget about SLE", or "let's not make things
for SLE while making it easier for TW". I understand that your PoV is
different, working cross-distro a lot. But please try understanding us,
too. There is a lot of intertia in an enterprise distribution, for good
Coming back to the original question - I could of course move e.g.
multipathd to /usr/sbin now - for TW. But on SLE or Leap, I would run
high risk of scripts (from the distro, 3rd party, qa, users, ...)
breaking because they expect it in /sbin. I can fix the distro scripts
(even that would be some effort to begin with, and pretty error-prone),
but I can do hardly anything about the rest. I don't think we'd gain
anything if I move the binary to /usr/sbin and create a separate
symlink in /sbin. Therefore I believe strongly that multipathd in SLE
will remain in /sbin. OTOH, I try to avoid growing too many differences
between TW and SLE/Leap spec files, too, and keep conditionals in spec
files on a comprehensible level.
In this case at least, I find it pretty obvious that simply keeping
/sbin is the least error-prone and the least problematic approach, and
will automatically do "the right thing" after the usr merge in TW, as