Scott Ferguson wrote:
On 18/11/14 23:14, Miles Fidelman wrote:
Scott Ferguson wrote:
On 18/11/14 15:06, Miles Fidelman wrote:
<snipped>
Scott Ferguson wrote:
On 18/11/14 12:54, Miles Fidelman wrote:
<snipped> I left out sendmail, but I just checked, and guess
what, no systemd service file in upstream).
xy?
Ummm.... those are NOT systemd scripts shipped by the upstream
sendmail developers.
Your point was noted - hence the "xy?" comment.
ummm.... that's awfully cryptic
Not if you are a programmer, or read this list often.
http://mywiki.wooledge.org/XyProblem
Can't say that I've ever come across it used on this list.
And while I can't claim to be much of a programmer, at least these
days, I've managed and worked with an awful lot of programmers, and I
can honestly say that I've never come across the term in general usage.
Of course, your mileage may vary.
However - I don't 'believe' it's a relevant point.
A. Mail servers don't care about init systems. Quite the reverse.
B. systemd's ain't systemd's (e.g. what constitutes "systemd" varies
according to release and distro). (i.e. ~/.bashrc from debian isn't
identical to upstreams).
Are you kidding me?
No.
Mail servers generally start up automatically as
system services, and need to get restarted if they die. How does that
not involve the init system?
Please read again. I never said "mail servers do not involve the init
system" - I said "mail servers don't care about the init system". They
simply need to be initiated, and, depending on the admins desires,
monitored - typically by a daemon. Whether started by /etc/rc.local,
cron/acron, or *any* init system - mail servers don't care.
I still don't think I'm seeing your point. Mail servers, and servers in
general need to be initialized, usually rely on the o/s init system, and
generally come packaged with a collection of init and utility scripts.
To date, every single major server we rely on, for a relatively standard
collection of web, mail, list, and database servers comes stock with
ONLY sysvinit scripts.
To me, that's "caring" about the init system. Can you elaborate on what
you mean by "don't care?"
<snipped>
To ensure I wasn't falling into the trap of confirmation bias - before
checking upstream for init support I'd be asking myself if it was
necessary (cart before horse?).
e.g. Why *should* sendmail ship *a* systemd .session file? After all
sendmail developers have to support a wide range of systems and
apportion resources according to their definition of needs.
1. Compared to configuring sendmail correctly it's trivial to create one
to suit the usecase.
2. Like sendmail itself there is no "one-size-all" session/timer
configuration.
3. If the user installs from a distro repostitory they get a "default"
.session file to match the distro. (If the distro is going to do the
work why should upstream do it?)
They ship sysvinit scripts, period. Which is
my point.
I suspect the logic you base the point upon is flawed.
./configure
make; make test; make install
Apropos of what??!!
pretty much works for pretty much any major server application
It "pretty much" works to *build* any package; test the build, and then
(crudely) install it.
- which
includes installing init scripts from upstream that just work
"Pretty much" i.e. sometimes. IMO it's too generic to apply a process
that's designed to work in non-specific situations to *specific*
situations - in this case, Debian.
Well, for all of the servers I've installed, I've at various times
installed from upstream source, on multiple distros, and BSD, and things
"just worked."
The gnu autotools are pretty clever that way.
packaging adds some convenience in handling dependencies and managing
system configuration, usually at the expense of running well behind what
comes from upstream (and checkinstall makes it pretty easy to integrate
upstream source into package management)
Agreed. But, "huh"?? You talk of a need for stability then choose
bleeding edge corner cases.
At various times, I've found the packaged versions of mission-critical
software to lag way behind upstream - particularly in the case of the
list management software we use, and at times, antispam and antivirus
software. Also, some of the stuff we experiment and develop with
(various NoSQL databases, and Erlang). Sometimes waiting for packaging
to catch up just doesn't cut it (anti-spam stuff, for example - always
looking at new tools there).
I worry a lot more about stability in the sense of environment and
regression testing. I really don't like it when my platform changes
under me. Applications, I expect to change.
<snip>
Agreed. Though the Debian way isn't always what upstream supports - and
often I've found their "Debian" package is actually Ubuntu packaging, so
I've had to tweak things (likewise checkinstall and rpm conversions
don't always work). That's the price of choosing the bleeding edge don't
you think?
But, to date, the Debian way has always provided a pretty stock Linux
environment (LSB, etc.) - that allows for situations where Debian
packages aren't available. And, by and large, when I review the
Debian-specific changes to a package, they're usually pretty minor.
(Yes, I tend to read changelog.Debian and README.debian files :-)
but... when upstream provides sysvinit scripts, that adds complexity
and/or extra code:
Yes, though:-
;I don't expect upstream to support all distros and releases
;I had many LSB errors from upstream sysvinit scripts - so as a rule I
expect problems when installing packages from upstream. Lack of support
for downstream *is to be expected*.
As noted above, my experience is a little different. I've generally
found things to just work when I install them from upstream - on Debian
in particular.
I guess that one of my concerns is that I've found a lot of stuff that I
play with - cluster stuff, virtualization stuff, some NoSql databases -
seem to be developed on Debian first, but in the form of raw source
code, not packages. I'm kind of worried that major changes in the
Debian platform might change that.
- either the packager has to write systemd init info (one more thing to
go wrong and that should be regression tested), or,
- systemd has to handle the init script properly - again one more thing
to go wrong, particularly if the upstream script runs afoul of one of
the documented (or undocumented) incompatibilities in systemd's handling
of init scripts (and why should upstream have to worry about that when
they code?)
Agreed "pretty much". Lack of support for downstream *is to be
expected*. If you have a problem with that take it upstream.
Well... I kind of look at it the other way around. A distro is a
platform. It's job is to provide a hospitable environment for
installing stuff from upstream. And a mix of flexibility and stability
is what makes a platform hospitable. If I have problems with a
platform, I'm going to change platforms, not "take it upstream."
Maybe not the greatest analogy, but....
- My personal laptop is a Mac - partly because I've been using Macs
forever, partly because I like the general form, fit, and function, but
mostly because it's the most versatile platform around (I can run
commercial applications, native unix code, and pretty much anything else
in a virtual machine).
- My work laptop is Windows based - because the company issues it, and
because Microsoft's business stuff actually is quite good supporting
organizations (outlook, sharepoint, active directory, etc.).
- My (small) server farm (legacy of once owning a hosting company, now
used to provide pro-bono hosting to a bunch of local nonprofits and
community groups, as well as providing a development sandbox for future
endeavors) -- started as Solaris, migrated to RedHat, then migrated to
Debian and has been Debian for maybe 15 years
In all cases, I've tended to rely on code as "packaged" by its creators:
- for Macs, it's either installer files or .dmg files
- for Windows, it's installer files
- for *nix, I use packaged stuff for all the routine, environmental
stuff (libraries, tools, utilities, and stuff), while more often than
not building critical applications from upstream source (.tar.gz source
files are a package)
From this perspective, systemd seems to be creating instabilities,
reducing flexibility, and generally making Debian (and many other
distros) far less hospitable platforms. It's a headache I don't need,
for zero benefit to our environment.
Major upstream application developers do not seem to be
jumping on systemd.
More important than trying to find evidence of a negative 'might' be
determining whether there is a need. If there is none[*1] then the
absence of proof has little value.
[*1]you mention sendmail, which is widely deployed on distros that use
systemd *despite* upstream not distributing systemd "support" - because
upstream "support" for systemd is redundant. Do you have something less
fuzzy than "major upstream application developers"?? It's puzzling as
this is Debian and most of us use the *Debian packaged* version of
upstream so the relevance is difficult to discern.
Again, this seems like a backwards perspective. When I put on my
product manager's hat (which I've done at one time in my life), from a
developer's point of view, one generally tries to develop for
cross-platform compatibility. Having to package, or be packaged for a
specific environment is a major inconvenience - especially when said
packaging relies on human beings. From an upstream point of view, the
goal is to develop for the least-common-denominator that's supported
across the broadest range platforms used by one's target users.
As I see it, a critical consideration for platform builders is to make
life easy for upstream, not the other way around.
Again, not the greatest analogy, but people buy windows, because there's
software available for it, that isn't available elsewhere. That's
because developers develop for Windows, not because Windows packagers do
their thing.
If anything, what I'm seeing are "oh sh&t, I
guess we should develop systemd service units at some point."
Read again please - I haven't said that at all, only that your claim
that as upstream sendmail doesn't ship with systemd service units
"proves" sendmail doesn't support systemd is false logic.
But that's not what I said. What I said is that upstream sendmail
developers don't see any need to develop for systemd - presumably
because a., they don't need any capabilities not already provided,
pretty much universally, by the sysvinit system, and b., because
sysvinit scripts are supported pretty much everywhere (for now).
From an upstream perspective, the goal is to write software, and ship
it in a form that can be readily used on lots of platforms, WITHOUT the
need for additional packaging. Autotools and cross-compilers are the
tools of choice. Packaging is a convenience for users, to simplify
handling dependencies.
From an upstream perspective, increased use of systemd, just makes
lives more difficult - once can no longer count on simply including a
set of sysvinit scripts with confidence that they'll just work. At a
minimum, they have to start worrying about incompatibilities between
their init scripts and systemd's implementation of sysvinit. Beyond
that, they have to either rely on packagers, or start including systemd
service files. That just strikes me as a less desirable situation -
more things to go wrong, more people and steps in the delivery chain.
<snip>
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546c18c0.4030...@meetinghouse.net
