Re: switching from exim to postfix

[Andrei POPESCU]

On Sb, 28 apr 12, 19:12:42, Russ Allbery wrote:
> 
> There's nothing particularly wrong with Exim; it works just fine.  It's
> been the default in Debian for years, and it's actively maintained
> upstream.  And it's completely trivial to replace it with Postfix if one
> desires.  The disruption doesn't seem worth it even if we had consensus
> that Postfix was marginally better in some way.

What about dma?

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Svante Signell]

On Sat, 2012-04-28 at 02:29 +0200, Vincent Bernat wrote:
> OoO Vers la  fin de l'après-midi du vendredi 27  avril 2012, vers 16:29,
> Svante Signell  disait :
> 
> > Apparently it can today ... with init scripts, which _new_ features will
> > be brought in for the _boot_ process. udev takes care of the events,
> > already today, right? More secure boot, faster boot (coreboot), better
> > debugging, simple ways of logging the boot massages, etc? Don't talk
> > about plug-and-p{r}ay, that is not interesting for _boot_: Found new
> > hardware, eh?
> 
> But that's the whole point : new hardware pops up while booting. See for
> example a server that will need  a 3G connection. The 3G connection will
> be done  by some  classic USB key.  When the  USB key is  detected, udev
> triggers a script  asking the USB key (which defaults  to a mass storage
> device) to  switch to  "modem mode".   Once it becomes  a modem,  the 3G
> connection  can be initialized.   Turning the  USB key  into a  modem is
> taking   some  time.   The   USB  key   will  be   "disconnected",  then
> "reconnected". SO, "found new  hardware".  ifupdown scripts were already
> run and filed with "interface not found".

Nice description, thanks. However, this is not necessarily part of the
_boot_ process!! This could/should happen _after_ the computer is up and
running, e.g. when starting X. You are not able to use your USB modem
until then anyway, and boot times should be as short as possible, not
having to wait for a dongle to connect to the wireless network. So, the
real problem is: How do you define the boot process of a computer. For
me it is when the kernel has been loaded by the boot media, memory,
graphics card, etc initialized. Some modules are needed for boot, other
modules can be loaded later. The only case I can see when you need a
network during the boot process is when booting from the network, and
for that you can predefine which modules to load.

> udev can run simple actions when a device appears but cannot run a chain
> of dependencies  (start the  3G connection, run  some daemon  that needs
> Internet  which in  turn  will trigger  some  client to  this daemon  to
> run). The solution is an event-based init. We want a reliable boot.

Then the functionality of udev should be extended, not dragging the
init scripts into this udev<->Linux kernel interaction. I think it
would be much better to isolate these two instead of having a third
(potentially buggy) software included. 

> We are in 2012 and if a non-essential daemon blocks the boot (no working
> network), we have no way to get a getty to be run.

See the reply from Thomas Goirand.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1335691553.1819.47.camel@x60

Re: switching from exim to postfix

[George Danchev]

On Sun, 29 Apr 2012 12:05:06 +0300, Andrei POPESCU 
 wrote:

On Sb, 28 apr 12, 19:12:42, Russ Allbery wrote:


There's nothing particularly wrong with Exim; it works just fine.  
It's

been the default in Debian for years, and it's actively maintained
upstream.  And it's completely trivial to replace it with Postfix if 
one
desires.  The disruption doesn't seem worth it even if we had 
consensus

that Postfix was marginally better in some way.


What about dma?


Well, dma does not listen on port 25 for incoming connections, it 
accepts
mails from local MUAs and delivers them to either the local mailboxes 
or remote
(full-fledged) SMTP servers. I'm sure there would be people claiming 
that such a

feature reduction, read simplification, would be a decent default.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e390a773a4a37f4230b63983521e8...@spnet.net

Re: RFC: OpenRC as Init System for Debian

[Bernd Zeimetz]

On 04/27/2012 07:33 PM, Tollef Fog Heen wrote:
> ]] Martin Wuertele 
> 
>> * Josselin Mouette  [2012-04-27 09:53]:
>>
>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
> Yes of course, because event-driven init systems have *always* been
> *only* about mounting USB devices. 

 Then explain the _real_ reasons for having an event driven boot system!
>>>
>>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
>>
>> That's a reason for udev/mdev, however I still fail to see why this
>> results in the requirement for an event based boot process. 
> 
> A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
> mounted and /srv/somewhere comes off iscsi, which means it requires
> networking to be up, which means network drivers loaded, etc.  So the
> event «network driver loaded» causes ifup to be spawned, which causes
> $network to be satisfied which causes the iscsi daemons to be started
> which causes mount to be called.

You actually want to start your iscsi stuff even your network is not available
right now - and you for sure don't want to stop it just because the link flaps.
iscsi is able to handle that just fine. You could even add multipath on top of
iscsi to make it even more reliable. And for all that there is no need to have
an init system which understands events. If you want to do something after your
devices appear, use udev. As traffic yo your iscsi disk will be queued in case
the connection gets lost there is also no need to find something new to handle
link up/down events. If your link is gone forever there is a broken filesystem
and some stuck IO fun anyway.

You have to find something better to convince people.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9d3909.2090...@bzed.de

Re: RFC: OpenRC as Init System for Debian

[Bernd Zeimetz]

On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
>> On 04/27/12 03:32, Adam Borowski wrote:
>>> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
 On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> I believe Debian still supports running locally compiled kernels
> which do not depend on udev, and that some setups do not require
> udev either (not everyone use fibre channel).
 
 It is supported only in the sense that it is not yet impossible.
 
 Please don't ask anyone to spend time to avoid udev dependencies; 
 hotplugging is normal and udev is the proper way to handle all 
 devices the Linux kernel finds.
>> 
>> udev is just the reference implementation. mdev [part of busybox] can do 
>> the same (modulo rules: it has a slightly simpler format that doesn't 
>> provide exactly the same features (yet))
> [...]
> 
> Sure, for Linux in general you have other options like mdev.  However, 
> Debian uses udev.


Debian installs udev by default, but as with other init systems it should not
stop your from using whatever-you-like instead of udev.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9d3b4f.8040...@bzed.de

Re: RFC: OpenRC as Init System for Debian

[Miles Bader]

Svante Signell  writes:
> So, the
> real problem is: How do you define the boot process of a computer. For
> me it is when the kernel has been loaded by the boot media, memory,
> graphics card, etc initialized. Some modules are needed for boot, other
> modules can be loaded later. The only case I can see when you need a
> network during the boot process is when booting from the network, and
> for that you can predefine which modules to load.

Isn't mounting filesystems, which can depend on the network, part of
the boot process?

I recently had an unpleasant experience where I switched to
network-manager to make gnome-shell happy, but network-manager runs
too late in the boot process, so none of my NFS filesystems got
mounted.

I certainly wished there was a bit more proper ordering going on
then...

-miles

-- 
Philosophy, n. A route of many roads leading from nowhere to nothing.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87haw2irxf@catnip.gol.com

Bug#670837: ITP: python-cliff -- command line interface formulation framework

[Jan Dittberner]

Package: wnpp
Severity: wishlist
Owner: Jan Dittberner 

* Package name: python-cliff
  Version : 0.4
  Upstream Author : Doug Hellmann 
* URL : https://github.com/dreamhost/cliff
* License : Apache License 2.0
  Programming Lang: Python
  Description : command line interface formulation framework

Cliff is a framework for building command line programs. It uses
plugins to define sub-commands, output formatters, and other
extensions.

The cliff framework is meant to be used to create multi-level commands
such as subversion and git, where the main program handles some basic
argument parsing and then invokes a sub-command to do the work.

-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Stephan Seitz]

On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote:

Isn't mounting filesystems, which can depend on the network, part of
the boot process?


Yes, but how do you check if the network is configured and operational?
- when the link is up?
- when the IP address is configured (how do you check this with IPv6?)?  
  What are you doing if more than one IP address is configured for this 
  NIC or more than one NIC is available?

- when the switch accepts traffic on the port you are connected to?
- when the router/firewall accepts traffic from your IP address?

No event based init system will solve these problems when you have 
dependencies outside the box you are booting. The local admin has to 
check if all timings are right and must adjust them if they are not 
fitting.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: RFC: OpenRC as Init System for Debian

[Ben Hutchings]

On Sun, 2012-04-29 at 14:59 +0200, Bernd Zeimetz wrote:
> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> > On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
> >> On 04/27/12 03:32, Adam Borowski wrote:
> >>> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
>  On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> > I believe Debian still supports running locally compiled kernels
> > which do not depend on udev, and that some setups do not require
> > udev either (not everyone use fibre channel).
>  
>  It is supported only in the sense that it is not yet impossible.
>  
>  Please don't ask anyone to spend time to avoid udev dependencies; 
>  hotplugging is normal and udev is the proper way to handle all 
>  devices the Linux kernel finds.
> >> 
> >> udev is just the reference implementation. mdev [part of busybox] can do 
> >> the same (modulo rules: it has a slightly simpler format that doesn't 
> >> provide exactly the same features (yet))
> > [...]
> > 
> > Sure, for Linux in general you have other options like mdev.  However, 
> > Debian uses udev.
> 
> 
> Debian installs udev by default, but as with other init systems it should not
> stop your from using whatever-you-like instead of udev.

Of course, Debian has many derivative distributions that use some
alternate components.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Harald Jenny]

On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:
> On 12-04-28 at 01:50pm, Joey Hess wrote:
> > Jonas Smedegaard wrote:
> > > As I understand the current status, it has already on this list been 
> > > resolved that *both* packages should back off from using the 
> > > clashing name "node".
> > > 
> > > I also am biased in one direction but shall not say which as I see 
> > > no benefit at this point in rehashing the discussion: Both packaging 
> > > "camps" have clearly demonstrated a lack of interest in letting the 
> > > other use the name "node", which means we must both step off of it.

Hi all,

I'm not sure if such this solution was already thought of so I have
choosen to present my approach:

A new package named node is created which contains two symlinks
/usr/(s)bin/node, a debconf question, link managing scripts and some
sort of trigger.
Both conflicting packages get a NMU by a neutral member renaming the
node command and adding a dedepency on the new package named node.
When installing only one of the two packages it automatically gets the
node link and everybody is happy.
If both are installed the person is presented a debconf question which
allows him to choose which node* should be the one.

Wouldn't this solve the whole dilemma in a policy compliant and easy
enough fashion that it could be used or what error is there in my idea?

Have a nice sunday
Harald Jenny


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120429135826.ga14...@harald-has.a-little-linux-box.at

Re: RFC: OpenRC as Init System for Debian

[Miles Bader]

Stephan Seitz  writes:
>>Isn't mounting filesystems, which can depend on the network, part of
>>the boot process?
>
> Yes, but how do you check if the network is configured and operational?
> - when the link is up?
> - when the IP address is configured (how do you check this with
> IPv6?)?  What are you doing if more than one IP address is configured
> for this NIC or more than one NIC is available?
> - when the switch accepts traffic on the port you are connected to?
> - when the router/firewall accepts traffic from your IP address?
>
> No event based init system will solve these problems when you have
> dependencies outside the box you are booting. The local admin has to
> check if all timings are right and must adjust them if they are not
> fitting.

Er, what?   Please don't throw out silly strawmen...

-miles

-- 
Inhumanity, n. One of the signal and characteristic qualities of humanity.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vheipu5@catnip.gol.com

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Marco d'Itri]

On Apr 29, Harald Jenny  wrote:

> Wouldn't this solve the whole dilemma in a policy compliant and easy
> enough fashion that it could be used or what error is there in my idea?
If fixing a real world problem requires so much overhead because of 
policy concerns then it looks like the policy needs to be fixed.
Policy is not a religion.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Marco d'Itri]

On Apr 29, Russ Allbery  wrote:

> desires.  The disruption doesn't seem worth it even if we had consensus
What kind of disruption are you thinking about?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Bernd Zeimetz]

On 04/29/2012 04:11 PM, Ben Hutchings wrote:
> On Sun, 2012-04-29 at 14:59 +0200, Bernd Zeimetz wrote:
>> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
>>> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
 On 04/27/12 03:32, Adam Borowski wrote:
> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
>> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard
>> wrote:
>>> I believe Debian still supports running locally compiled
>>> kernels which do not depend on udev, and that some setups do
>>> not require udev either (not everyone use fibre channel).
>> 
>> It is supported only in the sense that it is not yet impossible.
>> 
>> Please don't ask anyone to spend time to avoid udev dependencies;
>>  hotplugging is normal and udev is the proper way to handle all 
>> devices the Linux kernel finds.
 
 udev is just the reference implementation. mdev [part of busybox] can
 do the same (modulo rules: it has a slightly simpler format that
 doesn't provide exactly the same features (yet))
>>> [...]
>>> 
>>> Sure, for Linux in general you have other options like mdev.  However,
>>>  Debian uses udev.
>> 
>> 
>> Debian installs udev by default, but as with other init systems it should
>> not stop your from using whatever-you-like instead of udev.
> 
> Of course, Debian has many derivative distributions that use some alternate
> components.


Please stop trolling.
There is no reason why we should not allow people to use mdev or whatever they
like instead of udev.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9d4faf.1060...@bzed.de

Re: RFC: OpenRC as Init System for Debian

[Bernd Zeimetz]

On 04/29/2012 04:18 PM, Miles Bader wrote:
> Stephan Seitz  writes:
>>> Isn't mounting filesystems, which can depend on the network, part of
>>> the boot process?
>>
>> Yes, but how do you check if the network is configured and operational?
>> - when the link is up?
>> - when the IP address is configured (how do you check this with
>> IPv6?)?  What are you doing if more than one IP address is configured
>> for this NIC or more than one NIC is available?
>> - when the switch accepts traffic on the port you are connected to?
>> - when the router/firewall accepts traffic from your IP address?
>>
>> No event based init system will solve these problems when you have
>> dependencies outside the box you are booting. The local admin has to
>> check if all timings are right and must adjust them if they are not
>> fitting.
> 
> Er, what?   Please don't throw out silly strawmen...


Stephan's points are valid. Just having a link on your favourite cisco does not
mean that you are allowed to send packets anywhere yet. Getting a ipv6 address
via radvd does not mean that you are able too access your nfsv4 server (and the
other way round...). And so on.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9d5093.7000...@bzed.de

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Harald Jenny]

On Sun, Apr 29, 2012 at 04:23:25PM +0200, Marco d'Itri wrote:
> On Apr 29, Harald Jenny  wrote:
> 
> > Wouldn't this solve the whole dilemma in a policy compliant and easy
> > enough fashion that it could be used or what error is there in my idea?
> If fixing a real world problem requires so much overhead because of 
> policy concerns then it looks like the policy needs to be fixed.
> Policy is not a religion.
> 
> -- 
> ciao,
> Marco

Agreed but how long would it take to fix the policy vs how long would it
take to produce this package in the face of next stable release?

Kind regards
Harald Jenny


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120429143251.gb14...@harald-has.a-little-linux-box.at

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Marco d'Itri]

On Apr 29, Harald Jenny  wrote:

> Agreed but how long would it take to fix the policy vs how long would it
> take to produce this package in the face of next stable release?
The current situation does not even cause any practical problems, just 
a policy violation.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Ben Hutchings]

On Sun, 2012-04-29 at 16:26 +0200, Bernd Zeimetz wrote:
> On 04/29/2012 04:11 PM, Ben Hutchings wrote:
> > On Sun, 2012-04-29 at 14:59 +0200, Bernd Zeimetz wrote:
> >> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> >>> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
>  On 04/27/12 03:32, Adam Borowski wrote:
> > On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
> >> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard
> >> wrote:
> >>> I believe Debian still supports running locally compiled
> >>> kernels which do not depend on udev, and that some setups do
> >>> not require udev either (not everyone use fibre channel).
> >> 
> >> It is supported only in the sense that it is not yet impossible.
> >> 
> >> Please don't ask anyone to spend time to avoid udev dependencies;
> >>  hotplugging is normal and udev is the proper way to handle all 
> >> devices the Linux kernel finds.
>  
>  udev is just the reference implementation. mdev [part of busybox] can
>  do the same (modulo rules: it has a slightly simpler format that
>  doesn't provide exactly the same features (yet))
> >>> [...]
> >>> 
> >>> Sure, for Linux in general you have other options like mdev.  However,
> >>>  Debian uses udev.
> >> 
> >> 
> >> Debian installs udev by default, but as with other init systems it should
> >> not stop your from using whatever-you-like instead of udev.
> > 
> > Of course, Debian has many derivative distributions that use some alternate
> > components.
> 
> 
> Please stop trolling.
> There is no reason why we should not allow people to use mdev or whatever they
> like instead of udev.

I'm perfectly serious.  You may be able to do that today, but you should
not expect it to work and should not report a bug if you are later
forced to install udev as a depdendency of some other package.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


signature.asc
Description: This is a digitally signed message part

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO En  cette fin de  matinée radieuse du  dimanche 29 avril  2012, vers
11:25, Svante Signell  disait :

>> But that's the whole point : new hardware pops up while booting. See for
>> example a server that will need  a 3G connection. The 3G connection will
>> be done  by some  classic USB key.  When the  USB key is  detected, udev
>> triggers a script  asking the USB key (which defaults  to a mass storage
>> device) to  switch to  "modem mode".   Once it becomes  a modem,  the 3G
>> connection  can be initialized.   Turning the  USB key  into a  modem is
>> taking   some  time.   The   USB  key   will  be   "disconnected",  then
>> "reconnected". SO, "found new  hardware".  ifupdown scripts were already
>> run and filed with "interface not found".

> Nice description, thanks. However, this is not necessarily part of the
> _boot_ process!! This could/should happen _after_ the computer is up and
> running, e.g. when starting X. You are not able to use your USB modem
> until then anyway, and boot times should be as short as possible, not
> having to wait for a dongle to connect to the wireless network.

There is no  X. It is a _server_. Its  only available network connection
is through this 3G  usb dongle. If it does not happen  on boot, it never
happens.

>> udev can run simple actions when a device appears but cannot run a chain
>> of dependencies  (start the  3G connection, run  some daemon  that needs
>> Internet  which in  turn  will trigger  some  client to  this daemon  to
>> run). The solution is an event-based init. We want a reliable boot.

> Then the functionality of udev should be extended, not dragging the
> init scripts into this udev<->Linux kernel interaction. I think it
> would be much better to isolate these two instead of having a third
> (potentially buggy) software included. 

The  functionality of  udev should  be extended  to  manage dependencies
between system daemons? Isn't the job of init?
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)


pgpXpWSv0JZZH.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO Pendant le repas du samedi 28 avril 2012, vers 19:54, Thomas Goirand
 disait :

>> We are in 2012 and if a non-essential daemon blocks the boot (no working
>> network), we have no way to get a getty to be run.
>> 
> I agree with the rest of your post, but here, you are are
> picturing a very badly written init script that doesn't have
> a working failure mode! No daemon should block the boot,
> even with our current system. If it does, please feel free to
> file a bug.

There  is no  bug. When  using  start-stop-daemon on  a forking  daemon,
start-stop-daemon waits for the  process to detach which usually happens
when the  process is ready to  accept incoming requests. If  it needs to
establish some network connections, it will not fork before.

I am  not building some  random theoritical situation here.   It happens
with exim  and cfengine  for example. And  it also happens  when mouting
network drives. Even if you have  your root ready, you won't get a getty
after long long long timeouts.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)


pgpDnk6aK2pJC.pgp
Description: PGP signature

Re: switching from exim to postfix

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Apr 29, Russ Allbery  wrote:

>> desires.  The disruption doesn't seem worth it even if we had consensus

> What kind of disruption are you thinking about?

Existing users who are familiar with Exim and who would get Postfix on a
new install and be surprised.

The giant endless flamewars on debian-devel required to make a decision to
change anything.  :)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa1uqxuh@windlord.stanford.edu

Re: switching from exim to postfix

[Julien Cristau]

On Sun, Apr 29, 2012 at 09:58:14 -0700, Russ Allbery wrote:

> m...@linux.it (Marco d'Itri) writes:
> > On Apr 29, Russ Allbery  wrote:
> 
> >> desires.  The disruption doesn't seem worth it even if we had consensus
> 
> > What kind of disruption are you thinking about?
> 
> Existing users who are familiar with Exim and who would get Postfix on a
> new install and be surprised.
> 
> The giant endless flamewars on debian-devel required to make a decision to
> change anything.  :)
> 
The 500 packages that would have to change their Depends from "exim4 |
mta" to something else.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Roger Leigh]

On Sun, Apr 29, 2012 at 07:03:11PM +0200, Julien Cristau wrote:
> The 500 packages that would have to change their Depends from "exim4 |
> mta" to something else.

The brokenness of having to have a default package hardcoded in
every virtual dependency rather than having a virtual defaults
package and/or central list is an insanity I wish we could have
fixed years ago.  We should not have global policy WRT virtual
package defaults embedded (inconsistently!) into every single
dependency!


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429170701.ge28...@codelibre.net

Re: switching from exim to postfix

[Russ Allbery]

Julien Cristau  writes:

> The 500 packages that would have to change their Depends from "exim4 |
> mta" to something else.

Well, it would be nice to change all of those to depend on default-mta |
mail-transport-agent anyway, but yeah.  Making that low-priority change
urgent would be sort of annoying.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5pepitj@windlord.stanford.edu

Re: switching from exim to postfix

[Raphael Hertzog]

On Sun, 29 Apr 2012, Julien Cristau wrote:
> The 500 packages that would have to change their Depends from "exim4 |
> mta" to something else.

We're already on our way to update them with "default-mta |
mail-transport-agent".

That would provide an incentive to finish converting the dependencies :-)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429170856.gb1...@rivendell.home.ouaza.com

Re: switching from exim to postfix

[Marco d'Itri]

On Apr 29, Russ Allbery  wrote:

> > What kind of disruption are you thinking about?
> Existing users who are familiar with Exim and who would get Postfix on a
> new install and be surprised.
This does not really look like a big surprise.
If somebody is familiar enough with Exim to modify the default configuration
then I think it is safe to assume that he also knows how to install the 
package.

> The giant endless flamewars on debian-devel required to make a decision to
> change anything.  :)
IIRC, last time we discussed this I think that even the exim maintainers 
were in favour of the change...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Julien Cristau]

On Sun, Apr 29, 2012 at 19:08:56 +0200, Raphael Hertzog wrote:

> On Sun, 29 Apr 2012, Julien Cristau wrote:
> > The 500 packages that would have to change their Depends from "exim4 |
> > mta" to something else.
> 
> We're already on our way to update them with "default-mta |
> mail-transport-agent".
> 
On a very slow way.  I know.  That's beside the point.

> That would provide an incentive to finish converting the dependencies :-)
> 
If you need disruption to do it then probably changing the default isn't
all that important.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Marco d'Itri]

On Apr 29, Russ Allbery  wrote:

> The giant endless flamewars on debian-devel required to make a decision to
> change anything.  :)
Unrelated: you have just shown what poisons Debian and has been keeping 
us behind innovation for the last years.
Not the flamewars themselves, most of us are grown ups and can handle 
them, but the fear that proposing a change will cause endless 
discussions and no results.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Andrey Rahmatullin]

On Sun, Apr 29, 2012 at 07:16:18PM +0200, Marco d'Itri wrote:
> > The giant endless flamewars on debian-devel required to make a decision to
> > change anything.  :)
> IIRC, last time we discussed this I think that even the exim maintainers 
> were in favour of the change...
What were the reasons?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Joerg Jaspert]

On 12831 March 1977, Marco d'Itri wrote:
> Is this the right time to do it?

No.

It never will be.

It's insane to even think of switching one full featured MTA against
another full featured one. It feels like "gosh, i dislike $onepiece,
lets all move to $differentpiece", though both are bad as default.

If you really want to invest work, the time is much better spent in
getting one of those tiny replacements a default. And then anyone who
wants/needs a real one can change. Much more useful that way.

-- 
bye, Joerg
Die dümmsten Hähne haben die dicksten Eier.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k40y78dt@gkar.ganneff.de

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Fri, Apr 27, 2012 at 08:49:24AM +0200, Adrian Knoth wrote:
> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> 
> > I believe Debian still supports running locally compiled kernels which 
> > do not depend on udev, and that some setups do not require udev either 
> > (not everyone use fibre channel).
> 
> And then, there is this statement about the core distro:
> 
>"There are a number of folk in the Linux ecosystem pushing for a
> small core of tightly coupled components to make the core of a modern
> linux distro. The idea is that this “core distro” can evolve in sync
> with the kernel, and generally move fast. This is both good for the
> overall platform and very hard to implement for the “universal”
> distros."

I hope I'm not alone in feeling quite uneasy about the implications
of the above.

One of the definining characteristics of the Linux ecosystem, including
Debian, has been that the system has been made up of a set of loosely-
coupled compoments with well-defined interfaces.  This is in stark
contrast to, e.g. Windows, MacOS and other proprietary systems, which
have extremely tight coupling between their components, and where being
able to swap out one component for another is almost unheard of.  Given
that this loose coupling has enabled experimentation with a wide
variety of different solutions to problems, and allowed the evolution
of a diverse range of different packages to solve a very wide variety
of needs, it could be considered one of the defining factors in the
success of Linux.  Quite why we would want to replace this with a
one-size-fits-all solution beggars belief.

Given the ongoing debate regarding the different init systems we might
want to adopt long-term, I think this is perhaps one of the less
discussed factors, but perhaps one of the more important ones.  Both
systemd and upstart are technically superior to all the alternatives,
systemd perhaps more so.  But while the technical advantages are nice,
these come at the cost of reducing the amount of diversity in the
system, and our ability to replace pieces which don't fit our needs
due to the tight coupling.

While sysvinit is clearly inferior, it gives us (Debian) something the
others do not: control over our own destiny, and the ability to
modify every aspect of it and the init scripts to fit our needs.  Both
systemd and upstart are largely influenced by third parties.  As a
trivial example: systemd creates user session information in
/run/user/$user .  I brought up with lennart the fact that this would
only permit one session per user.  He rejected out of hand the fact
that more than one session would ever be needed, because Gnome only
allowed one session per user.  So the limitations of Gnome in this
respect have led to a fundamental limitation in systemd's session
management.

We could patch and work around this type of brokenness easily enough.
But given the rapid speed at which systemd is growing and swallowing
up more and more functionality previously served by different tools,
would we have the ability and will to continue to patch every bit that
didn't fit our needs, and keep that working over time?  If we can't,
we'll potentialy end up with a technically superior system... which
meets the needs of Gnome/Fedora and other distributions, rather than
our own.  And when the primary maintainers have shown themselves to
be less than willing to accommodate even this simplest of requests
(as above; a single tempnam call would have been sufficient), would
we be committing ourselves to a less than desirable fate?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429174548.gf28...@codelibre.net

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Thu, Apr 26, 2012 at 01:42:48PM +0100, Roger Leigh wrote:
> I'm going to investigate it in more detail on a running Gentoo system
> and learn a bit more about it before doing anything.  If anyone fancies
> doing the packaging, I'll be happy to join in.  I'll probably be able
> to provide a better overview once I know a bit more.

Just to provide a bit more context for this discussion.  After
learning a bit more about how OpenRC works, thanks to their
assistance on IRC:

- OpenRC is a relacement for sysv-rc/insserv/startpar
- It still depends on sysvinit, though only for the initial
  inittab runlevel actions.
- It uses its own dependency system rather than LSB.  In some
  ways, it's nicer (starting a script manually will also start
  the required deps, something LSB scripts can not do), and most
  of the LSB deps will map to OpenRC deps (not sure about all the
  (X- variants yet)
- It looks like it will be possible to get OpenRC to run LSB
  scripts and cope with LSB dependencies, which would let us
  evaluate it in Debian.

So from the POV of the wider systemd/upstart debate, it's not
going to particularly affect that.  I think this could be
viewed as a potentially good upgrade from insserv/startpar.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429175717.gg28...@codelibre.net

non-event-based init systems are unfixable [Was: Re: RFC: OpenRC as Init System for Debian]

[Steve Langasek]

On Sun, Apr 29, 2012 at 03:59:03PM +0200, Stephan Seitz wrote:
> On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote:
> >Isn't mounting filesystems, which can depend on the network, part of
> >the boot process?

> Yes, but how do you check if the network is configured and operational?
> - when the link is up?
> - when the IP address is configured (how do you check this with
> IPv6?)?What are you doing if more than one IP address is
> configured for this   NIC or more than one NIC is available?
> - when the switch accepts traffic on the port you are connected to?
> - when the router/firewall accepts traffic from your IP address?

Retransmitting your packets because the network is not yet delivering them
is an entirely different error handling scenario from rebinding because your
service was started before the system has an address (or interface).  The
former is handled transparently by the protocol stack and the latter
requires every application to handle it manually - and the only way the
application can handle it is by stupid polling.

Linux is an event-based system, and we need to do event-based activation of
the software, so that we don't have to patch a hundred processes to poll for
the network to show up underneath them.

The fact that v6 addresses may come and go without generating events seen by
userspace is a deficiency with the current system; but a) it's a solvable
one, b) having reliable events for all the *other* scenarios is a huge
reliability improvement over the sysvinit status quo.

For some insight into how upstart structures its events to ensure reliable
start of network services on boot, see the Upstart Cookbook:

  http://upstart.ubuntu.com/cookbook/

> No event based init system will solve these problems when you have
> dependencies outside the box you are booting. The local admin has to
> check if all timings are right and must adjust them if they are not
> fitting.

IOW, "the admin has to add a bunch of sleep's everywhere"?  Pass, thanks.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429180920.gb25...@virgil.dodds.net

Re: switching from exim to postfix

[Joey Hess]

Joerg Jaspert wrote:
> It's insane to even think of switching one full featured MTA against
> another full featured one. It feels like "gosh, i dislike $onepiece,
> lets all move to $differentpiece", though both are bad as default.

Yeah, Debian has certianly never done that before ..
(Remember smail? It's still mentioned in Policy even!)

> If you really want to invest work, the time is much better spent in
> getting one of those tiny replacements a default. And then anyone who
> wants/needs a real one can change. Much more useful that way.

That would be a fairly viable route. Although it slightly begs the
question of what task-mail-server would then pull in instead.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On Apr 29, Roger Leigh  wrote:

> I hope I'm not alone in feeling quite uneasy about the implications
> of the above.
We can all be "uneasy" about it until we are blue in the face, but since 
Red Hat maintains most Linux core components and we do not, there is not 
much we can do about it.

> While sysvinit is clearly inferior, it gives us (Debian) something the
> others do not: control over our own destiny, and the ability to
> modify every aspect of it and the init scripts to fit our needs.  Both
> systemd and upstart are largely influenced by third parties.  As a
I do not consider settling for obsolete software to be a useful 
direction for Debian, nor is NIH a great argument in software design.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Svante Signell]

On Sun, 2012-04-29 at 20:19 +0200, Marco d'Itri wrote:
> On Apr 29, Roger Leigh  wrote:
> 
> > I hope I'm not alone in feeling quite uneasy about the implications
> > of the above.
> We can all be "uneasy" about it until we are blue in the face, but since 
> Red Hat maintains most Linux core components and we do not, there is not 
> much we can do about it.

Maybe GNU/Linux is not the bright future any longer. 

> > While sysvinit is clearly inferior, it gives us (Debian) something the
> > others do not: control over our own destiny, and the ability to
> > modify every aspect of it and the init scripts to fit our needs.  Both
> > systemd and upstart are largely influenced by third parties.  As a
> I do not consider settling for obsolete software to be a useful 
> direction for Debian, nor is NIH a great argument in software design.

Talking about NIH, is systemd not that if anything?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1335726410.1819.97.camel@x60

Re: RFC: OpenRC as Init System for Debian

[Fernando Lemos]

On Sun, Apr 29, 2012 at 2:45 PM, Roger Leigh  wrote:
> One of the definining characteristics of the Linux ecosystem, including
> Debian, has been that the system has been made up of a set of loosely-
> coupled compoments with well-defined interfaces.  This is in stark
> contrast to, e.g. Windows, MacOS and other proprietary systems, which
> have extremely tight coupling between their components, and where being
> able to swap out one component for another is almost unheard of.  Given
> that this loose coupling has enabled experimentation with a wide
> variety of different solutions to problems, and allowed the evolution
> of a diverse range of different packages to solve a very wide variety
> of needs, it could be considered one of the defining factors in the
> success of Linux.  Quite why we would want to replace this with a
> one-size-fits-all solution beggars belief.

Just to be clear, what you're describing is specific to systemd, not
to event-based init systems in general.

It's true that diversity fosters innovation. I think the question here
is, should Debian make technical choices based on whether or not the
resulting distribution is an ambient that fosters innovation on init
system design? And when I think of it that way, the answer seems to be
a resounding no.


> Given the ongoing debate regarding the different init systems we might
> want to adopt long-term, I think this is perhaps one of the less
> discussed factors, but perhaps one of the more important ones.  Both
> systemd and upstart are technically superior to all the alternatives,
> systemd perhaps more so.  But while the technical advantages are nice,
> these come at the cost of reducing the amount of diversity in the
> system, and our ability to replace pieces which don't fit our needs
> due to the tight coupling.

Just to be clear again, this is also specific to the current
event-based init implementations. It's not in any way a characteristic
of event-based init systems in general.

Integration versus flexibility is a tradeoff. At one end of the
spectrum, we have a very tightly integrated distribution, where
nothing is interchangeable. At the other end, we have the concept of
distribution as a simple collection of binaries with pretty much no
integration. Having a better integrated init system would push Debian
a little bit towards the former, no doubt.


> While sysvinit is clearly inferior, it gives us (Debian) something the
> others do not: control over our own destiny, and the ability to
> modify every aspect of it and the init scripts to fit our needs.  Both
> systemd and upstart are largely influenced by third parties.  As a
> trivial example: systemd creates user session information in
> /run/user/$user .  I brought up with lennart the fact that this would
> only permit one session per user.  He rejected out of hand the fact
> that more than one session would ever be needed, because Gnome only
> allowed one session per user.  So the limitations of Gnome in this
> respect have led to a fundamental limitation in systemd's session
> management.
>
> We could patch and work around this type of brokenness easily enough.
> But given the rapid speed at which systemd is growing and swallowing
> up more and more functionality previously served by different tools,
> would we have the ability and will to continue to patch every bit that
> didn't fit our needs, and keep that working over time?  If we can't,
> we'll potentialy end up with a technically superior system... which
> meets the needs of Gnome/Fedora and other distributions, rather than
> our own.  And when the primary maintainers have shown themselves to
> be less than willing to accommodate even this simplest of requests
> (as above; a single tempnam call would have been sufficient), would
> we be committing ourselves to a less than desirable fate?

That's certainly something we need to take into account. There's an
option you didn't mention: forking. I think it's better to fork than
to try to come up with something from scratch. When people write stuff
from scratch, 9 out of 10 times they just don't understand the problem
they're trying to solve. And if it's a big project (such as an init
system), it's very unlikely to ever get off the ground.


Regards,


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canvyna838ycfnqc7g0todrcjkdbsmpdjh-9zrsz4x4aymrh...@mail.gmail.com

Re: RFC: OpenRC as Init System for Debian

[Jonathan Nieder]

Marco d'Itri wrote:

> We can all be "uneasy" about it until we are blue in the face, but since 
> Red Hat maintains most Linux core components and we do not, there is not 
> much we can do about it.

I'll repeat what I said last time you made this (in my opinion
strange) argument:

Red Hat employs some eminently friendly and reasonable people.
Claiming that we are at their mercy is ignoring the ability to reason
with them.  (When that stops being true, we can talk about whether it
is time to work with other distros on a fork, but given that we're not
there yet, I wonder why you keep on raising the point.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429193024.GA28023@burratino

Definition of _boot_

[Svante Signell]

Hello,

In line with the recent discussion, lets aim at defining what _boot_ is:
- initializing the RAM: yes
- initializing the CPU(s): yes
- loading the kernel: yes
- initializing the graphics card: yes for text mode, graphics mode can
come later
- initializing the HDD(s): yes, if boot devices.
- setting up swap: yes
 -initializing the keyboard and mouse : yes, see below wrt USB
- initializing the serial device: no, only if used for debugging.
- initializing the the parallel port: no
- initializing the audio card: can be done later
- initializing USB devices: yes if keyboard, mouse or boot device, other
things can be done later.
- starting up the network: yes if network booting, other things can be
done later.
- starting an MTA: no
- staring sshd: no
- starting X: no, that is not a _boot_ task,  other things can be done
later. This excludes network-manager and what follows with it.
- of course there are missing pieces here, you can help me filling them
in... or reject/not comment on this as usual as many of you would.

Thank you for your attention!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1335729097.1819.115.camel@x60

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Sun, Apr 29, 2012 at 08:19:44PM +0200, Marco d'Itri wrote:
> On Apr 29, Roger Leigh  wrote:
> 
> > While sysvinit is clearly inferior, it gives us (Debian) something the
> > others do not: control over our own destiny, and the ability to
> > modify every aspect of it and the init scripts to fit our needs.  Both
> > systemd and upstart are largely influenced by third parties.  As a
> I do not consider settling for obsolete software to be a useful 
> direction for Debian, nor is NIH a great argument in software design.

Just to be clear, I am by no means suggesting that we should stick
with sysvinit.  I am merely pointing out that there are important
factors to consider /in addition to/ the technical merits of the init
system.  With systemd we get a technically excellent system, but we are
also buying into a whole lot more than that, some good, some bad.

Keeping our options open, and evaluating what are options are
available and usable is important, and this is the principal reason
why I am interested in looking at OpenRC.  It doesn't hurt to try it 
out and see if it meets our needs.


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429201451.gh28...@codelibre.net

Re: switching from exim to postfix

[Christoph Anton Mitterer]

On Sun, 2012-04-29 at 03:13 +0200, Marco d'Itri wrote:
> Is this the right time to do it?
I'd vote for it :)

Or better said for depending on a default-mta which is going to be
postifx, as already outlined.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Definition of _boot_

[Jonathan Nieder]

Svante Signell wrote:

> In line with the recent discussion, lets aim at defining what _boot_ is:

Why?  Unless you are suggesting documentation is unclear, I don't see
how this has any impact on the development of Debian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429204859.GA31883@burratino

Re: Definition of _boot_

[Ben Hutchings]

On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote:
> Hello,
> 
> In line with the recent discussion, lets aim at defining what _boot_ is:
[...]

No, let's not.  Beyond RAM, CPU, IRQ controllers and timers (all
of which are part of the kernel's early initialisation) pretty
much all of this varies from system to system and potentialy from
boot to boot.

Further, if I normally log in to my laptop through gdm then gdm most
certainly is part of the boot process *on that laptop*.  And if I set
up a Debian-based system as a web kiosk, starting the web browser is
also part of the boot process *on that system*.
 
Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429205247.gq3...@decadent.org.uk

Re: RFC: OpenRC as Init System for Debian

[Fernando Lemos]

On Sun, Apr 29, 2012 at 5:14 PM, Roger Leigh  wrote:
> Keeping our options open, and evaluating what are options are
> available and usable is important, and this is the principal reason
> why I am interested in looking at OpenRC.  It doesn't hurt to try it
> out and see if it meets our needs.

Agreed on the "keeping our options open" part. But given that the
kernel is increasingly event-based, OpenRC seems to be a step
backwards. I agree that OpenRC would be an improvement over the status
quo, but migrating *away* from OpenRC later on would be a major pain
as we would have to support both LSB/sysvinit scripts and OpenRC
service descriptions for the foreseeable future.

Regards,


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canvyna8w36re26qaxeyxegna4e_tqpyrkp3+t1omhaqa4-_...@mail.gmail.com

Re: switching from exim to postfix

[Carsten Hey]

* Joey Hess [2012-04-29 14:22 -0400]:
> Joerg Jaspert wrote:
> > It's insane to even think of switching one full featured MTA against
> > another full featured one. It feels like "gosh, i dislike $onepiece,
> > lets all move to $differentpiece", though both are bad as default.

Looks like the DragonFly Mail Agent (dma), which already has been
mentioned in this thread, could become a decent default for Wheezy+1
after some small changes.

In a nutshell: it's able to deliver locally and remotely, has a queue,
supports TLS/SSL, does not listen on port 25 and instead of running as
daemon, it if run every 5 minutes via cron to flush the queue.  Maybe it
could be changed to use incron and not cron on Linux.  It's
README.Debian contains more verbose information.

It currently lacks support for .forward files, ignores -bs, misses -F,
ignores -om and the newaliases command exits with 1 if run without
arguments.  I'm nore sure if the latter two are problematic.


> Yeah, Debian has certianly never done that before ..
> (Remember smail? It's still mentioned in Policy even!)

JFTR: According to [1] and [2], the reason to switch away from smail was
that exim are easier to configure.

 [1] http://lists.debian.org/debian-devel/1998/11/msg00415.html
 [2] http://lists.debian.org/debian-devel/1998/11/msg00489.html


> > If you really want to invest work, the time is much better spent in
> > getting one of those tiny replacements a default. And then anyone who
> > wants/needs a real one can change. Much more useful that way.
>
> That would be a fairly viable route. Although it slightly begs the
> question of what task-mail-server would then pull in instead.

If there will ever be a Debian user survey (again?), this question would
be a good fit.  At least GRML did user surveys in the past:
http://grml.org/survey2011-results/


Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429205045.ga23...@furrball.stateful.de

Bug#670875: ITP: logsurfer -- Monitoring system logs in real-time

[Thilo Uttendorfer]

Package: wnpp
Severity: wishlist
Owner: Thilo Uttendorfer 

* Package name: logsurfer
  Version : 1.8
  Upstream Author : Kerry Thompson 
* URL : http://www.crypt.gen.nz/logsurfer/
* License : BSD
  Programming Lang: C
  Description : Monitoring system logs in real-time

Logsurfer is a program for monitoring system logs in real-time, and reporting
on the occurrence of events.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120429210635.3942.66571.reportbug@kent.simpsons

Re: Definition of _boot_

[Svante Signell]

On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote:
> On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote:
> > Hello,
> > 
> > In line with the recent discussion, lets aim at defining what _boot_ is:
> [...]
> 
> No, let's not.  Beyond RAM, CPU, IRQ controllers and timers (all
> of which are part of the kernel's early initialisation) pretty
> much all of this varies from system to system and potentialy from
> boot to boot.

I'd assume that. Thank you.

> Further, if I normally log in to my laptop through gdm then gdm most
> certainly is part of the boot process *on that laptop*.  And if I set
> up a Debian-based system as a web kiosk, starting the web browser is
> also part of the boot process *on that system*.

Then why can't we define what _boot_ is then? Single user, multi-user,
desktop, laptop, server, with or without X (soon wayland) etc?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1335733868.1819.118.camel@x60

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On Apr 29, Jonathan Nieder  wrote:

> Red Hat employs some eminently friendly and reasonable people.
I am on friendly terms with many Red Hat people, but it is a fact that 
they take design decisions which are aligned with the needs of RHEL 
and these needs are often far from what is good for other distributions.
This has been happening more and more after SuSE has become irrelevant.

I will cite just a few simple examples:
- no good strategy to prevent lockstep udev/kernel upgrades, since RHEL 
  does not support upgrading to the next major release
- configuration files in /etc/ overriding configuration files in /lib/, 
  to work around the inferior configuration files handling of RPM
- removal from udev/systemd of features which Red Hat will not provide 
  anymore (e.g. support of persistent names for new network interfaces,
  choose your own example for systemd)

> Claiming that we are at their mercy is ignoring the ability to reason
> with them.
The problem is not "reasoning", in my experience Red Hat people will 
promply agree that different distributions can make different choices.
But nowadays they just refuse to support these choices.
Obviously this is their prerogative, but it is also a fact which we need 
to be aware of.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Roger Leigh wrote:
> One of the definining characteristics of the Linux ecosystem, including
> Debian, has been that the system has been made up of a set of loosely-
> coupled compoments with well-defined interfaces.  This is in stark
> contrast to, e.g. Windows, MacOS and other proprietary systems, which
> have extremely tight coupling between their components, and where being
> able to swap out one component for another is almost unheard of.  Given
> that this loose coupling has enabled experimentation with a wide
> variety of different solutions to problems, and allowed the evolution

Recent innovation related to init systems has largely happened in
systemd. More conservative approaches have failed to show enough
progress to solve even the immediate problems. IMO there's enough
evidence that the part which needed new innovation was the interfaces
and the integration between them, not the individual pieces trying to
work within the limitations of the old interfaces.


> While sysvinit is clearly inferior, it gives us (Debian) something the
> others do not: control over our own destiny, and the ability to
> modify every aspect of it and the init scripts to fit our needs.  Both
> systemd and upstart are largely influenced by third parties.

> But given the rapid speed at which systemd is growing and swallowing
> up more and more functionality previously served by different tools,
> would we have the ability and will to continue to patch every bit that
> didn't fit our needs, and keep that working over time?  If we can't,
> we'll potentialy end up with a technically superior system... which
> meets the needs of Gnome/Fedora and other distributions, rather than
> our own.

You're not offering any competitive alternative to systemd. In fact,
you're pretty much saying that that it's not realistic to maintain an
alternative. If you're given a choice between using Debian from 10 years
ago or the latest Fedora, would you choose the old Debian because "it
was made for our needs"? I think there's a quite direct equivalence
between preferring the 10-year-old Debian and preferring to stay with
sysvinit just to "control our own destiny".



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1335733859.1766.23.camel@glyph.nonexistent.invalid

Bug#670876: ITP: php-sabredav -- SabreDAV allows you to easily add WebDAV support to a PHP application

[Thomas Mueller]

Package: wnpp
Severity: wishlist
Owner: Thomas Mueller 

* Package name: php-sabredav
  Version : 1.6.2
  Upstream Author : Evert Pot 
* URL : http://www.http://sabredav.org/
* License : BSD
  Programming Lang: php
  Description : SabreDAV allows you to easily add WebDAV support to a PHP 
application

SabreDAV is meant to cover the entire standard, and attempts to allow 
integration using an easy to understand API.

Feature list:

Fully WebDAV compliant
Supports Windows XP, Windows Vista, Mac OS/X, DavFSv2, Cadaver, Netdrive, 
Open Office, and probably more.
Passing all Litmus tests.
Supporting class 1, 2 and 3 Webdav servers.
Locking support.
Custom property support.
CalDAV (tested with Evolution, iCal, iPhone and Lightning).
CardDAV (tested with OS/X addressbook, the iOS addressbook and Evolution).
Over 97% unittest code coverage. 

Supported RFC's:

RFC2617: Basic/Digest auth.
RFC2518: First WebDAV spec.
RFC3744: ACL (some features missing).
RFC4709: DavMount.
RFC4791: CalDAV.
RFC4918: WebDAV revision.
RFC5397: current-user-principal.
RFC5689: Extended MKCOL.
RFC6352: CardDAV
draft-daboo-carddav-directory-gateway: CardDAV directory gateway
CalDAV ctag, CalDAV-proxy. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120429204352.3587.56610.reportbug@localhost.localdomain

Re: Definition of _boot_

[Carsten Hey]

* Svante Signell [2012-04-29 21:51 +0200]:
> In line with the recent discussion, lets aim at defining what _boot_ is:

I'm rather sure that he wants to define booting as part of what
currently is done in /etc/rcS.d.  Configuring the network or mounting
non-essential remote file systems wouldn't be part of this definition.

Then he would state that these early tasks do not need events at all,
and conclude that later tasks can be handled in event based userspace
tools, but that the initial process that invokes these event based tools
doesn't require events and thus can stay simple.


Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429214803.gb23...@furrball.stateful.de

Re: Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Marco d'Itri wrote:
> I am on friendly terms with many Red Hat people, but it is a fact that 
> they take design decisions which are aligned with the needs of RHEL 
> and these needs are often far from what is good for other distributions.

> - configuration files in /etc/ overriding configuration files in /lib/, 
>   to work around the inferior configuration files handling of RPM

I'm not convinced that the traditional Debian way of directly editing
package-created files under /etc would be preferable. I think the
etc-overrides-lib alternative is technically superior in many ways: the
original version is kept in a known location, it's trivial to
(temporarily) revert to defaults when you suspect a problem is caused by
local configuration, it's easier to see what has been locally modified
and what hasn't, and especially if the program supports file inclusion
(to include then override the default version) you can resolve more
updates without needing to do 3-way merges by hand.

The main argument against etc-overrides-lib has been that dpkg can
automatically give warnings about some of the cases where you may need
to update your local configuration. But this ability isn't really
inherent to the directly-editing case, nor only implementable with it. I
think this is better characterized as a case of Debian preferring an
inferior format because that's the only thing its existing tools already
support, while Red Hat is free to choose the superior format without
drawbacks as it never had such tools at all.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1335739797.1766.43.camel@glyph.nonexistent.invalid

Re: Definition of _boot_

[Ben Hutchings]

On Sun, Apr 29, 2012 at 11:11:08PM +0200, Svante Signell wrote:
> On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote:
> > On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote:
> > > Hello,
> > > 
> > > In line with the recent discussion, lets aim at defining what _boot_ is:
> > [...]
> > 
> > No, let's not.  Beyond RAM, CPU, IRQ controllers and timers (all
> > of which are part of the kernel's early initialisation) pretty
> > much all of this varies from system to system and potentialy from
> > boot to boot.
> 
> I'd assume that. Thank you.
> 
> > Further, if I normally log in to my laptop through gdm then gdm most
> > certainly is part of the boot process *on that laptop*.  And if I set
> > up a Debian-based system as a web kiosk, starting the web browser is
> > also part of the boot process *on that system*.
> 
> Then why can't we define what _boot_ is then? Single user, multi-user,
> desktop, laptop, server, with or without X (soon wayland) etc?
 
Ignoring special boot modes for the moment, the system is booted when
its usual services are available.  Exactly what those usual services
are is determined by package selection and local configuration.  We
cannot make an exhaustive definition.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429232754.gr3...@decadent.org.uk

Re: Definition of _boot_

[Chow Loong Jin]

On 30/04/2012 03:51, Svante Signell wrote:
> - starting up the network: yes if network booting, other things can be
> done later.
> - starting an MTA: no
> - staring sshd: no

On my remotely administered Debian server, these three are *definitely* part of
the boot process, and it's not network booting.

I have no idea where you pulled your definition of _boot_ out from, but my
definition of _boot_ is the process of initializing hardware, and starting up
every service needed to get the machine into its usual running state.

From wikipedia:
> In computing, booting (also known as booting up) is the initial set of
> operations that a computer system performs when electrical power is switched 
> on.
> The process begins when a computer that has been turned off is re-energized, 
> and
> ends when the computer is ready to perform its normal operations. 

Read: "ends when the computer is ready to perform its normal operations."

Is a remotely administered machine "ready to perform its normal operations" 
when:-
1. The network is still down? No.
2. SSH is still down? No.
3. (in the case of a mail server) MTA is still down? No.


Thank you. Now let's please stop this farce.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: switching from exim to postfix

[Adam Borowski]

On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote:
> Looks like the DragonFly Mail Agent (dma), which already has been
> mentioned in this thread, could become a decent default for Wheezy+1
> after some small changes.
> 
> In a nutshell: it's able to deliver locally and remotely, has a queue,
> supports TLS/SSL, does not listen on port 25 and instead of running as
> daemon, it if run every 5 minutes via cron to flush the queue.

I hope you mean: to run retries (in which case every 5 minutes is an
overkill).

Delaying every outgoing mail by 5 minutes doesn't sound like a good idea to
me.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429235934.ga16...@angband.pl

Re: switching from exim to postfix

[Russ Allbery]

Adam Borowski  writes:
> On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote:

>> Looks like the DragonFly Mail Agent (dma), which already has been
>> mentioned in this thread, could become a decent default for Wheezy+1
>> after some small changes.
>> 
>> In a nutshell: it's able to deliver locally and remotely, has a queue,
>> supports TLS/SSL, does not listen on port 25 and instead of running as
>> daemon, it if run every 5 minutes via cron to flush the queue.

> I hope you mean: to run retries (in which case every 5 minutes is an
> overkill).

> Delaying every outgoing mail by 5 minutes doesn't sound like a good idea
> to me.

I think that was Carsten's point about switching to incron, which would
then do the right thing for new outgoing mail.  You'd still need timed
handling of queued mail for retries.

(I was not previously familiar with incron; what a neat idea!)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehr6xdo8@windlord.stanford.edu

Bug#670887: ITP: volti -- control audio volume from system tray/notification area

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: volti
  Version : 0.2.3
  Upstream Author : Milan Nikolic 
* URL : http://code.google.com/p/volti/
* License : GPL
  Programming Lang: Python
  Description : control audio volume from system tray/notification area

 Volti is a lightweight GTK+ application for controlling audio
 volume from system tray/notification area.
 .
 Features:
  * no PulseAudio, GStreamer, Phonon etc. only ALSA is needed
  * internal mixer application, either choosing any mixer app
is possible
  * left click opens volume scale (slider)
  * scroll wheel on tray icon changes volume, increment in
percents is configurable
  * configurable middle click to toggle 'mute' or 'show mixer'
  * nice tooltip with card and volume info
  * support for multimedia keys
  * support desktop notifications on keys events



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120430012226.13091.72615.reportbug@alessio-laptop

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Thu, Mar 08, 2012 at 12:26:46AM +0900, Charles Plessy a écrit :
> 
> Thanks (and thanks Cyril) for the hint.  Still there are two things
> I do not understand:
> 
>  - Why and when it is a problem to add preprocessor flags in CFLAGS.
> 
>  - Why we chose the solution that require more extensive changes
>to the packages.

Sorry to rant again, but am I the only one thinking that we are in most of the
case wasting everybody's time by not simply passing all the hardening flags by
default in CFLAGS ?  In my experience (and I maintain more than 100 packages),
it is extremely rare to need to ensure that the compiler, preprocessor and
linker flags are in three separate variables.

When we need to modify a large number of packages in order to propagate a
change, isn't this meaning that we are not picking the most efficient defaults ?

Anyway, I am starting to push some makefile patches upstream.  And in the
meantime, I am not doing anything particularly interesting for Debian.  In
contrary, I spend less time, because the tedious micromanagement of the
compiler flags is so boring and looks so useless, yet it is necessary to enable
hardening flags that are 'important' in our BTS.  Seriously, which package in
Debian directly benefits from the split of the hardening flags in three
separate variables ?  What other features than hardening are using this ?

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120430023116.ga1...@falafel.plessy.net

Re: RFC: OpenRC as Init System for Debian

[Miles Bader]

Bernd Zeimetz  writes:
>> Er, what?   Please don't throw out silly strawmen...
>
> Stephan's points are valid. Just having a link on your favourite cisco does 
> not
> mean that you are allowed to send packets anywhere yet. Getting a ipv6 address
> via radvd does not mean that you are able too access your nfsv4 server (and 
> the
> other way round...). And so on.

No, his "points" are strawmen.  Nothing is perfect, and there are no
absolute guarantees of _anything_, but there are things which can
generally assumed to be work in practice (in particular anything
outside the current box).

If there are ipv6 / nfsv4 interoperability issues, that's a shame, but
it certainly shouldn't be used as an excuse to gimp the entire system,
when it may work fine for people using ipv4 and nfsv3...

That's what it sounds like Stephan is doing:  "oh it can't be perfect,
so let's not even try to be good."

-miles

-- 
gravity a demanding master ... soft soft snow


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwblhoth@catnip.gol.com

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Bernd Zeimetz 

> You actually want to start your iscsi stuff even your network is not
> available right now - and you for sure don't want to stop it just
> because the link flaps.

You need to wait for the right IP to become available so it can bind to
the right place.  And why would you stop networking because the link
flaps?

> If you want to do something after your devices appear, use udev.

udev has, intentionally, short timeouts and it should just trigger
services starting, it shouldn't run init script and such itself.

-- 
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". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa1t7pbd@qurzaw.varnish-software.com

Re: Definition of _boot_

[Svante Signell]

On Sun, 2012-04-29 at 23:48 +0200, Carsten Hey wrote:
> * Svante Signell [2012-04-29 21:51 +0200]:
> > In line with the recent discussion, lets aim at defining what _boot_ is:
> 
> I'm rather sure that he wants to define booting as part of what
> currently is done in /etc/rcS.d.  Configuring the network or mounting
> non-essential remote file systems wouldn't be part of this definition.
> 
> Then he would state that these early tasks do not need events at all,
> and conclude that later tasks can be handled in event based userspace
> tools, but that the initial process that invokes these event based tools
> doesn't require events and thus can stay simple.

Nice summary, thanks. This is the whole idea behind defining boot...
Some people get it, others don't.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1335766549.1819.121.camel@x60

Re: RFC: OpenRC as Init System for Debian

[Jonathan Nieder]

Marco d'Itri wrote:

> This has been happening more and more after SuSE has become irrelevant.
>
> I will cite just a few simple examples:
> - no good strategy to prevent lockstep udev/kernel upgrades, since RHEL 
>   does not support upgrading to the next major release
> - configuration files in /etc/ overriding configuration files in /lib/, 
>   to work around the inferior configuration files handling of RPM
> - removal from udev/systemd of features which Red Hat will not provide 
>   anymore (e.g. support of persistent names for new network interfaces,
>   choose your own example for systemd)

Thanks for explaining.  Very interesting examples.

Possible conclusions:
- we need to be involved upstream in core projects if we do not want to
  be neglected
- improving OpenSuSE and other distros is another way to help upstreams
  remember how to support more than one setup
- helping RPM and other Red Hat infrastructure is valuable, so they can
  experience the features that it would be nice to preserve in Debian
- sometimes package maintenance involves hard dilemmas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120430064417.GA10890@burratino