On 03/24/2014 09:22 PM, Peter Robinson wrote:
I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora. There has been a request in systemd upstream to disable support
for it by default, but I am not sure I want to do that unless we can
maybe say goodbye to it for the big picture too.
I have decided now to drop all support for tcpwrap from systemd, for the
next release. For those who believe that tcpd is really a good idea
(yuck!) not much is lost though, they can just plug in tcpd into
systemd, the way they did it with good old inetd, too, hence we are not
taking anything away there, we are pretty much compatible with what
inetd supported there (or actually: didn't support there).
I am not going to file a feature for Fedora, to remove support for it
entirely across the whole distro. I still think dropping it is the right
thing to do, but I don't think it's a good use of my own time, to fight
this through... I'd be happy though if somebody else would pick this
up. Looking at the current FESCO members I am not entirely sure though
whether a proposal to disable libwrap would have a chance in the current
cycle though. (also, M. Miller kinda supported the proposal, which as
history tells us means he probably is _not_ going to vote for it in the
end...)
It's a pity though that nobody in Fedora is actively working on getting
rid of legacy cruft. I really wished we had some people who oversee
deprecating things more proactively, figure out how to deprecate things,
write stub code to provide smooth transitions, write release notes and
so on. Being at the bleeding edge of things also means deciding that
some things really should go, from time to time... Besides deprecating
old cruft like libwrap, this would also mean removing all the old crap
from comps "standard" that we still install by default (894110)...
Interesting! You sent the email starting this thread a mere 4 days
ago, two of those a weekend. You've not given it a chance to even go
to FESCo meeting for discussion. Did you send it in the same way to
the rest of the distros that depend, or are soon to depend on, systemd
now.... SuSE, Arch, Debian, Ubuntu etc giving them no chance to
discuss the impact before you unceremoniously tear a feature, for
some, out?
Ultimately I've long stopped using tcpwrappers (a decade or so ago in
fact) so it doesn't bother me what so ever but I know of a LOT of
people that use it, rightly or wrongly, extensively.
systemd is now, or soon will be, a core component of pretty much all
major and minor distributions out there and it's no longer just about
you Lennart and your thoughts of whether it's "Yuck!" or not, you are
now similar to the kernel and like the kernel you should have a proper
deprecation process that is not just what you, Kay and who ever the
main developers decide is cool or not at the time. You should give us
and distributions in general more than 4 days to deal with what lives
or not. Ultimately systemd is no longer in nappies and is all grown
up, while you are still it's father it's now a teenager and needs to
be somewhat independent of it's father, it has friends that now depend
on it and there's should be a central place where these architectural
changes and deprecation intentions are announced, discussed and in the
case of deprecation given more than 4 days before removal.
I'm not sure where this is coming from but Arch removed this 3 years ago
and the original request of removal from upstream came from opensuse
with Debian responding they will be keeping this around for a while ( it
will be like 4 years in my gestimation for Debian to catch up with
systemd integration anyway so this is hardly a pressing concern for them
) so Lennart was being rather conservative of it's removal upstream
atleast not without checking with us ( Fedora ) first since we were the
remaining part responding of the "big distro's" to his "heads up" .
From broader view this boils down to how long should unmaintained core
os components be kept around, which is something that should be hashed
out among relevant upstreams in next plumbers session to establish a
clear path forward and arguably upstreams should be responsible to make
the decisions when things should be deprecated forcing downstream to
either adapt new modern way's or maintain stuff downstream with
themselves chose they do so instead of adapt.
By the way the kernel does not have a proper deprecation process which
is accurately reflected in all the code that is bit-rotting there so
it's not the holy grail of code maintenance as you let it out to be.
It lacks it's Boothby's to snip out the dead branches as much as we do
here with us.
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
