What exactly replaced base-config
So what exactly replaced base-config base-config provided a set of useful utilities that could be run AFTER Debian was installed to quickly fix certain aspect of a Debian system or to do quick chrooted post install tasks. I've been told by some that it had become "replaced by the Debian installer", but in some regard it has been nothing but a huge step back. 1) It provided a much more user friendly way to recover a badly hosed Debian system. 2) It was an excellent tool to run post install tasks after you debootstrapped a linux install to a chroot. Especially for argument 2, I'm expecting someone to say "just do it by hand", but as of now I don't see any way to run the installer udebs in the bootstrapped chroot, or another method to run post install options "the right way(tm)". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The future of the boot system in Debian
Could someone please point me to a discussion on the pros and cons of upstart that was not funded by that spacecowboy shuttleworth? Michael Biebl wrote: Petter Reinholdtsen wrote: The future of the boot system in Debian === [..] The planned time frame for this is to replace /sbin/init with upstart for Squeeze, and see if we manage to change the very early boot to [..] Petter Reinholdtsen, Kel Modderman, Armin Berres Due to an oversight from my side, I missed to sign this announcement. As maintainer of upstart I obviously was involved in the discussion and planning and I support this plan. Regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /var/www is depracated, which directory to use?
Russ Allbery wrote: Steve McIntyre writes: I'm still unconvinced by /srv personally - we've strived for years in Debian to make things work as much as possible straight from initial installation, yet now we're expected to deliberately leave services unconfigured. I don't think this is progress for most of our users... I don't think /srv is the answer to any question about "where do Debian packages put data in their default configuration." /srv is really intended to be a place where the local system administrator organizes their service data, which means we need to let them choose to organize it however they wish. I think the real problem here is that we have some missing integration glue. A lot of packages want to serve things out via the web by default unless the sysadmin has indicated that they want control over the URL space. Apache sort of provides a way to do that, but it isn't very good. Other web servers in Debian so far as I know don't at all. And there isn't a common interface supported by all of them. I think we need to put together a standard definition of how a Debian package can specify "please serve out this data and this CGI script at these URLs unless the sysadmin has said to leave the web configuration alone," using a standard API implemented by all web servers in Debian. I suspect that will get everyone what they want. I agree on this one. I personally prefer to keep files served by a webserver in /var/www/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Why does mysql-server depend on exim?
I just bootstrapped a fresh vm for some sandbox testing and came across the following issue. While installing mysql-server I noticed the following dependencies: "bsd-mailx exim4 exim4-base exim4-config exim4-daemon-light" Although it's not that big of a deal, it does raise the question "Why should a database server require a MTA?" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
