On Mon, Jul 30, 2012 at 12:10:33PM +0200, Vincent Lefevre wrote:
> > This invokes the service ("runs the init.d script") with invoke-rc.d, if
> > available. The rsync postscript should not need to check for invoke-rc.d
> > anymore, it's been available in a required package for a long time now,
> >
On 2012-07-30 12:01:08 +0200, Jonas Smedegaard wrote:
> On 12-07-30 at 12:37pm, Andrei POPESCU wrote:
> > I'd say there is a need for:
> >
> > 1. a system-wide setting to start daemons or not on boot/upgrades/etc.
> > 2. a blacklist - daemons listed here should not start no matter what
> > 3. a wh
On 2012-07-30 10:50:17 +0100, Lars Wirzenius wrote:
> I'm writing this on a machine running squeeze, so this may be a bit
> different in later versions, but here's the snippet:
>
> if [ -x /etc/init.d/rsync ]; then
> if dpkg --compare-versions "$oldversion" lt "3.0.7-2"; then
>
On 12-07-30 at 12:37pm, Andrei POPESCU wrote:
> On Lu, 30 iul 12, 11:12:43, Vincent Lefevre wrote:
> > On 2012-07-29 21:43:57 +0200, Wouter Verhelst wrote:
> > > An ENABLE switch does more than just disabling the run-at-boot
> > > state of an initscript. While I can buy the argument that some
> >
On Mon, Jul 30, 2012 at 11:12:43AM +0200, Vincent Lefevre wrote:
> > I do believe that whenever an initscript is called with the argument
> > "start", it should bloody well start, and not exit after doing
> > nothing because I haven't edited some scarcely related file
> > somewhere.
>
> As long as
On Lu, 30 iul 12, 11:12:43, Vincent Lefevre wrote:
> On 2012-07-29 21:43:57 +0200, Wouter Verhelst wrote:
> > An ENABLE switch does more than just disabling the run-at-boot state of
> > an initscript. While I can buy the argument that some packages should
> > not start *at boot* by default,
>
> Th
On 2012-07-29 21:43:57 +0200, Wouter Verhelst wrote:
> An ENABLE switch does more than just disabling the run-at-boot state of
> an initscript. While I can buy the argument that some packages should
> not start *at boot* by default,
The problem is not just at boot, but also when pacakges are insta
On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote:
> On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote:
> > Now, if you just mean removing enable/disable switches for initscripts from
> > /etc/default/*, that should be doable with some effort. And that's what
> > this s
On 2012-07-24 12:26:33 +0200, Tollef Fog Heen wrote:
> > If the package description had said that, it would have been
> > less confusing. It's strange for a package description to focus
> > on non-native features!
>
> I don't know what you mean by non-native features. Support for SysV
> init scri
On Tue, Jul 24, 2012 at 11:31:26AM +0200, Vincent Lefevre wrote:
> On 2012-07-24 08:16:43 +0200, Tollef Fog Heen wrote:
> >
> > I don't think it follows at all that because there are init systems
> > which conflict with sysvinit, Debian does not support multiple init
> > systems.
>
> But in such
]] Vincent Lefevre
> But in such a case, sysvinit shouldn't be an essential package (and
> packages that need it should thus have an explicit dependency on it),
> since it isn't really needed in a working Debian system.
And people are working towards that goal. We won't be there for wheezy,
but
On 2012-07-24 08:16:43 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre
> > >
> > > > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > > > ]] Vincent Lefevre
> > > > >
> > > > > > OK, if Debian pla
]] Russ Allbery
> Personally, I would love to see us create a common tool that would perform
> these sorts of actions for whatever init system one is using, whatever
> that may be. Maybe we can keep update-rc.d as that tool and teach it to
> take appropriate action for systemd, upstart, etc., wh
]] Vincent Lefevre
> On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> > ]] Vincent Lefevre
> >
> > > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > > ]] Vincent Lefevre
> > > >
> > > > > OK, if Debian plans to support other init systems, that's fine.
> > > >
> > > > It alre
Vincent Lefevre writes:
> A common interface would be nice. But what if there are multiple ways to
> disable a daemon (as mentioned by Tollef Fog Heen)? I think that it
> should be flexible enough so that the user can choose.
> IMHO it should also provide some logging mechanism for
> add/remove/
On 2012-07-23 17:59:21 +0100, Roger Leigh wrote:
> On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote:
> > No, I just mean that configuration of some service should be
> > in a limited number of places. But if you agree that it's fine
> > for /etc/default to override config setup somew
On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre
> > >
> > > > OK, if Debian plans to support other init systems, that's fine.
> > >
> > > It already does.
> >
> > Not really, or at le
On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote:
> On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> > > so that if you want to make things more consistent, you should
> > > get rid of /etc/default entirely.
> >
> > /
]] Vincent Lefevre
> On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > ]] Vincent Lefevre
> >
> > > OK, if Debian plans to support other init systems, that's fine.
> >
> > It already does.
>
> Not really, or at least not in a nice way, because sysvinit is
> an essential package.
How i
On 2012-07-23 15:26:29 +0200, Vincent Lefevre wrote:
> No, I just mean that configuration of some service should be
> in a limited number of places. But if you agree that it's fine
> for /etc/default to override config setup somewhere else, then
> there should not be any problem with ENABLE/DISABLE
On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> > so that if you want to make things more consistent, you should
> > get rid of /etc/default entirely.
>
> /etc/default is used for a lot more than just enabling/disabling services,
> a
On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > OK, if Debian plans to support other init systems, that's fine.
>
> It already does.
Not really, or at least not in a nice way, because sysvinit is
an essential package. Also, I don't see any init system that
provid
On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> so that if you want to make things more consistent, you should
> get rid of /etc/default entirely.
/etc/default is used for a lot more than just enabling/disabling services,
and it will not go away.
Now, if you just mean removing enable/disable switch
Le mercredi, 18 juillet 2012 13.04:36, Wookey a écrit :
> I don't use n-m because it doesn't play nice with usb0 gadget
> networking.
I have read this claim multiple times now and it got me confused: on a wheezy
laptop with network-manager and KDE, I can connect my Android phone trough USB
and g
]] Vincent Lefevre
> OK, if Debian plans to support other init systems, that's fine.
It already does.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
On 2012-07-22 16:40:48 +0200, Wouter Verhelst wrote:
> On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote:
> > On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote:
> > > ENABLE/DISABLE switches are *ugly*,
> >
> > I disagree. ENABLE/DISABLE switches have some advantages: they are
> >
Hi Michael,
On 2012-07-22 16:25:15 +0200, Michael Stapelberg wrote:
> Quoting Vincent Lefevre (2012-07-22 15:53:13)
> > I don't think there's anything wrong with enhancing the way that
> > sysvinit works, as long as the user can still use the update-rc.d
> > method.
> There is: update-rc.d is a de
On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote:
> On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote:
> > ENABLE/DISABLE switches are *ugly*,
>
> I disagree. ENABLE/DISABLE switches have some advantages: they are
> more readable than a set of symlinks,
That's just an opinion (on
Hi Vincent,
Quoting Vincent Lefevre (2012-07-22 15:53:13)
> I don't think there's anything wrong with enhancing the way that
> sysvinit works, as long as the user can still use the update-rc.d
> method.
There is: update-rc.d is a defined interface which works with sysvinit
and other init systems (
On 2012-07-22 14:11:41 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote:
> > I disagree. ENABLE/DISABLE switches have some advantages: they are
> > more readable than a set of symlinks, allow all the settings of some
> > service to be grouped in a single p
On 22.07.2012 11:43, Wouter Verhelst wrote:
> On Wed, Jul 18, 2012 at 12:04:36PM +0100, Wookey wrote:
>> 3) Network manager should have an /etc/default/ ENABLE/DISABLE switch
>> (as wicd does)
>
> I'm not a network-manager fan myself, but please do not do this.
>
> ENABLE/DISABLE switches are *ug
On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote:
> On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote:
> > ENABLE/DISABLE switches are *ugly*,
>
> I disagree. ENABLE/DISABLE switches have some advantages: they are
> more readable than a set of symlinks, allow all the settings of s
On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote:
> ENABLE/DISABLE switches are *ugly*,
I disagree. ENABLE/DISABLE switches have some advantages: they are
more readable than a set of symlinks, allow all the settings of some
service to be grouped in a single place, and can be managed more
easily
On Wed, Jul 18, 2012 at 12:04:36PM +0100, Wookey wrote:
> 3) Network manager should have an /etc/default/ ENABLE/DISABLE switch
> (as wicd does)
I'm not a network-manager fan myself, but please do not do this.
ENABLE/DISABLE switches are *ugly*, as their effect is not limited to
boottime changes.
]] Wookey
> 3) Network manager should have an /etc/default/ ENABLE/DISABLE switch
> (as wicd does)
[...]
> I do believe that at least one of the above should be done for wheezy.
Is there any reason whatsoever to have the setting in both /etc/default
and /etc/rcN.d?
I really wish we could get
Recommends is wrong for metapackages because it gets upgrades very
wrong. This is why it is used very marginally.
Couldn't this get fixed if
Depends: network-manager-gnome (>= 0.9.4)
was replaced with
Recommends: network-manager-gnome
Breaks: network-manager-gnome (<< 0.9.4)
--
To UNSUBS
+++ Ian Jackson [2012-07-13 23:48 +0100]:
> Adam Borowski writes ("Re: Recommends for metapackages"):
> > On Wed, Jul 11, 2012 at 09:32:19PM -0600, Philipp Kern wrote:
> > > On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote:
> > > > Installing N-M breaks unrelated software.
> >
37 matches
Mail list logo
