TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Dear Package Maintainers: Stop Being Clever

92 点作者 ajdecon将近 12 年前

14 条评论

bashtoni将近 12 年前
I posted this as a comment on the blog, but I&#x27;m duplicating here:<p>RHEL and Debian (and their respective derivatives) have different philosophies on packaging, which is why you see this result.<p>The RHEL philosophy is simple; package installation only installs the package, starting daemons is a separate process.<p>The Debian philosophy is that installing a daemon should also make that daemon run, unless it&#x27;s not possible the make the daemon run securely by default. Things like the &#x2F;etc&#x2F;default RUN=&quot;no&quot; aren&#x27;t the package maintainer trying to be clever, but rather them following Debian packaging guidelines. There also the reason you see things like MySQL listening only on the loopback interface by default on Debian.<p>One you understand this the decisions seem a bit less crazy.<p>For me, the big issue with the Debian approach isn&#x27;t on installation, but rather on upgrade. On Debian, running &#x27;apt-get upgrade&#x27; on a live server can cause an unspecified amount of downtime. If you&#x27;re upgrading MySQL, MySQL will get restarted. If you&#x27;re upgrading a library on which multiple daemons rely, they will also get restarted. yum upgrade on RHEL doesn&#x27;t suffer from the same problem, and you can schedule the restart yourself.<p>Again, this is because of a philosophical difference. On Debian, the idea is that if you&#x27;ve asked to upgrade something, it should be upgraded. On RHEL, you can upgrade a package, but continue to run the old (potentially insecure version).
评论 #6101438 未加载
评论 #6103946 未加载
txutxu将近 12 年前
What I don&#x27;t understand is why every maintainer adds a (unneeded) layer for enable&#x2F;disable.<p>If you want to run a service, you have a runlevel editor.<p>This is, chkconfig in RH based, and update-rc.d in debian based.<p>That is the tool for the job.<p>Nowadays it seems that everybody prefers to invent an additional switch, this is a shell boolean or string, in &#x2F;etc&#x2F;sysconfig (RH) or &#x2F;etc&#x2F;default (debian).<p>Why ?
belorn将近 12 年前
When packaging a daemon for Debian, the maintainer should add sufficient questions during installation, and sane default values, to start the service.<p>Contrary to the article, I think this is a rather good policy. It makes sure packages are usable as they are, rather than the normal process of config, make, make-install, and last adding user configuring before anything will start up. Debian is not Gentoo.<p>For those daemons which this isn&#x27;t possible, package maintainers has a harder time. One of the better ways is simply to have it run, but in a safe way which do nothing. That would solve the issues the article describes, and would not be harmful.
评论 #6101692 未加载
评论 #6101731 未加载
reidrac将近 12 年前
Every package maintainer needs to make some decisions when packaging software. Debian has very specific guidelines about packing, so if you don&#x27;t like it may be Debian is the wrong distribution _for you_.<p>Recently a workmate installed nginx from the upstream repo and... surprise: nginx packages things different to Debian. You may like it more or less, but there are different solutions for the same problem.
评论 #6102089 未加载
codezero将近 12 年前
I remember installing Red Hat 4, going on IRC and getting rooted. Red Hat&#x27;s approach comes from lots of learning, and I think it&#x27;s smart. Thanks for the post.
评论 #6101793 未加载
stonith将近 12 年前
We have a similar problem when deploying Openstack using puppet - all the services need to be brought up after config that sets things like the central DB and AMQP locations. It means that a deployed site will always have errors in their logs right from the start, which confuses customers and makes it harder to spot when there is actually an error in the deployment tool.
评论 #6101218 未加载
lmm将近 12 年前
Debian always think they know better than the authors of the software they&#x27;re distributing (the worst, but by no means only incident being their key generation bug). When I maintained a linux program I received twice as many bugs from Debian users as anything else, because Debian repackaged KDE in a way that broke its autoconf macros. And anyone who&#x27;s ever tried to follow a tutorial for e.g. Tomcat will know how radically Debian rearranges its files.<p>IMO it&#x27;s not worth maintaining Debian packages of one&#x27;s software or supporting it on Debian. Let Debian have their own packager for it if they want to, and direct support requests to them.
评论 #6102954 未加载
jmomo将近 12 年前
I hate to say it, but this is just a rant by a RedHat&#x2F;CentOS admin who has started using Debian&#x2F;Ubuntu for the first time and just doesn&#x27;t know why things are done differently there.
评论 #6102107 未加载
评论 #6102667 未加载
评论 #6101862 未加载
moe将近 12 年前
The author is spot on.<p>This has been a long-standing bug in Debian which, due to their glacial processes, will probably prevail eternally.<p>In theory it is possible to disable the post installation auto-start with a specially crafted &#x27;policy-rc.d&#x27;. In practice you don&#x27;t want to go there, as it tends to break in unexpected ways.
dmourati将近 12 年前
I answered the serverfault post.<p><a href="http://serverfault.com/a/526123/76707" rel="nofollow">http:&#x2F;&#x2F;serverfault.com&#x2F;a&#x2F;526123&#x2F;76707</a><p>I&#x27;m a longtime Redhat&#x2F;CentOS guy recently moved over to Ubuntu. It has definitely been a bit weird getting adjusted.<p>One counterpoint to the OP&#x27;s rant? SSH.
GrinningFool将近 12 年前
It seems like a lot of these comments are missing the point by discussing virtues of various packaging systems and auto-start behaviors.<p>It seems to me that the author was saying that consistency is important - installed services are expected to have a consistent behavior on a given platform.<p>A lot of tooling is built based on this, because that behavior is defined by the respective systems.<p>When people force override of these behaviors, it does break things as well as cause frustration.<p>The article isn&#x27;t a criticism of any one packaging system or autostart choice of a distribution, but rather of individual packagers who impose their own choices over those of the system they&#x27;re packaging for.
rlpb将近 12 年前
Debian&#x27;s thinking on this is that a user won&#x27;t install a daemon unless he wants it to run, and that a package should get everything into an immediately useable state by default. Therefore, a daemon should be started automatically when a package is installed.<p>I agree with the objection: I think that times have moved on, and in reality today people use configuration management tools and almost always want to change the default configuration on a server daemon. Therefore, it doesn&#x27;t make much sense to start it automatically.<p>As bashtoni says: this isn&#x27;t a problem with package maintainers. It&#x27;s a problem with Debian Policy.<p>A stepping stone to a full solution is to arrange a standard to configure the system not to start a daemon by default, and arrange for packages to follow that standard. policy-rc.d is just such a standard.
Qantourisc将近 12 年前
I agree on the autostart.
Chris2048将近 12 年前
I believe ElasticSearch will automatically connect to any nodes with the same cluster-name. The package installs it with the default cluster-name. Since it starts on install, you don&#x27;t have a chance to change this name before it&#x27;s done that...
评论 #6114944 未加载