Debian Developers - And now for something completely different... etch!

Author

And now for something completely different... etch!

Javier Fernández-Sanguino Peña

2005-06-06, 8:49 pm

Ok, so sarge has been released! We should all thank the Release Team for
their hard work in putting this major release together. But... how about we
start discussing about what major release goals we want to set for Etch?

So, without further delay, here's my "Etch-wishlist", it's biased on some
of the things I've personally worked on and would like to keep working on
for etch. I would love to hear the Release Managers opinion on what they
believe should be Release Goals for etch besides the things we all already
know about (non-free documentation purged from main, changes in supported
architectures...)

Feel free to add some new items or add (hopefully new) information to the
ones I list below:

--------------------------------------------------------------------------
[ Overall improvements ]
- _No_ bugs in base packages (well, at least no old bugs). Base system
should be upgraded to latest upstream (forward patches!) this includes
PAM, modutils...
* Base packages should be co-maintained and maintainers should be
open to help (not always the case currently)
See http://bugs.qa.debian.org/base-full.html
(Personal note: packages in base packages older than a year should either
be closed or handled properly, i.e. fixed)

[ Installation improvements ]
- Firewall configuration during installation (ala Fedora Core or SuSE):
module for d-i. Currently, the system is exposed just during installation
on some systems (empty root password?)
- Reduced standard installation (no gcc or development tools!, see
#301138 or #301273)
- More "tasks" (grouped packages) for installation: automatic detection
of user needs and automatic task selection?

[ Security improvements ]
- Proper package signature checks (apt-secure, currently on experimental)
- Buffer overflow protection: ExecShield or PaX in stock kernel
- Mandatory Access Control support: SELinux support (RSBAC?)
- Possibility to recompile the distro with SPP (apt-build?). New
i386-spp architecture?
- Proper source code audit by maintainers to detect stupid security
bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
too often. Automatic source code audit ala lintian.debian.org?
- MD5 / SHA-1 listing of files in ftp sites (useful for forensics analysis
see #303961)

[ Admin improvements ]
- Possibility to startup the OS in "control" mode: select which init
scripts will run, this provides a way to work-around hardware issues after
d-i has installed the base system (personal example: #301112)
- 'Status' in init.d scripts (#291148)
- hardware changes detection: system detects after a reboot when
a new SVGA card, new Ethernet card, etc. has been installed and prompts
for new confguration.
- inetd begone! -> xinetd (better mechanism to control DoS, privilege
separation, etc.)
- Checksecurity -> live up to its name and merge changes from other distros
and BSDs
- Security / Update managements of multiple servers from a single point.
There's no single tool to do check the security status of many servers
at once (like done in RedHat's Network). Use OVAL agents?
See #253097
- Better OS backup management -> upgrade rollback?
- Alternate bootup mechanism (dependancy based? see Solaris 10 or
http://www.atnf.csiro.au/people/rgo...x/boot-scripts/)
- Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5
- Using dpkg as an audit tool to detect changes in the system, not as
a security mechanism but to detect broken stuff (includes #155799 and #34194)

[ End user improvements ]
- Better help/documentation search (dwww sucks, dhelp needs improvement)
Provide a "Debian documentation center" with search functions to
detect information in READMEs, html files, manuals relevant to a
free-text query?
- Proper User/Sysadmin documentation guides (similar to what RedHat or
SuSE already provide, not FAQs or HOWTOs)
- I18n documentaion in CD-ROMs, better track of out-of-date translations
- Better package search mechanism (tags?) allowing free text search
in package management interfaces: "I want a program that does X"

[ Release improvements ]
- Prune packages from release based on popularity, packages which are not
used by anyone should not go in! (not enough peer review, probably
not audited, bug ridden with bugs, including security making security
handling a nightmare)
- Remove _all_ out of date dummy packages! (see #308711 and other bugs!)
- Better (not manual!) tracking of bugs associated with testing release
--------------------------------------------------------------------------

Regards

Javier

Marco d'Itri

2005-06-06, 8:49 pm

On Jun 07, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:

> - _No_ bugs in base packages (well, at least no old bugs). Base system
> should be upgraded to latest upstream (forward patches!) this includes
> PAM, modutils...
In my wishlist there is NO support of 2.4 kernels, so modutils would
become unneeded.
2.4.x kernels are already obsolete by now except that for some doorstop
architectures, I do not know about any other modern distribution which
still installs one.

> - inetd begone! -> xinetd (better mechanism to control DoS, privilege
> separation, etc.)
What about you try a decent inetd instead?
Anyway, I have in my wishlist being able to easily switch *inetd
daemons.

--
ciao,
Marco

Joey Hess

2005-06-07, 2:49 am

Javier Fernández-Sanguino Peña wrote:
> [ Installation improvements ]
> - Firewall configuration during installation (ala Fedora Core or SuSE):
> module for d-i. Currently, the system is exposed just during installation
> on some systems (empty root password?)

This has not really been discussed on debian-boot, but one of my
personal goals for a d-i improvement for etch is that the whole system
installation takes place in d-i, there is no separate base-config stage
and you boot straight from d-i into your installed desktop system (or
whatever).

This solves your problem fairly well, since the issue then becomes only
keeping d-i secure and keeping the installed system secure, not keeping
the system secure while it's installing itself. Daemons will not be
started dueing the installation, and will come up on reboot.

Some kind of firewall task would probably complete what you're looking
for here, so the installed system boots up with a complete firewall in
place.

> - Reduced standard installation (no gcc or development tools!, see
> #301138 or #301273)

Absolutely going to happen, but probably not in the the way most
commonly mentioned in these bug reports. I will acept patches to tasksel
that make it offer a "Standard system" task, that is selected by default
and can be de-selected. If noone sends patches, I'll get around to it
eventually, I suppose.

> - More "tasks" (grouped packages) for installation: automatic detection
> of user needs and automatic task selection?

Planned, and ground already laid in tasksel (and indeed, it does do it
for some easy things like language tasks). One thing I really want to
see happen is a laptop task. The big missing peice is some simple
program tasksel can call out to, like

if this_is_a_laptop; then
..
fi

This should use whatever hardware probing works best for laptops.

I'm interested in other ideas for automatic selection of default tasks.

> - hardware changes detection: system detects after a reboot when
> a new SVGA card, new Ethernet card, etc. has been installed and prompts
> for new confguration.

As long as this is in a package that can be purged and/or argued over
heatedly about whether it should be installed by default. :-) In other
words, not wanted on any machine I touch.

--
see shy jo

Grzegorz B. Prokopski

2005-06-07, 2:49 am

On Tue, 2005-07-06 at 01:03 +0200, Javier Fern=E1ndez-Sanguino Pe=F1a wrote=
:
> [ Installation improvements ]=20
> - Firewall configuration during installation (ala Fedora Core or SuSE):
> module for d-i. Currently, the system is exposed just during installati=
on
> on some systems (empty root password?)

Right. Especially for workstation installation something like below
would allow to connect from workstation to anywhere else, but not to
any servers ran on workstation.

# Already existing connections are allowed (incoming&related icmp too)
-A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
# all outgoing traffic is allowed
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p udp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

My impression was that firewall setting is generally a messy business,
because there's too many packages that mess with it, usually assuming
they're the only ones who touch it. This was, I think part of the
reason why /etc/init.d/iptables was removed (I still use it on all of
my old and newly installed machines, btw.) But maybe I am wrong and
somebody else could provides more details here.

> - 'Status' in init.d scripts (#291148)

....and 'zap'. Altough it's a solution from 'should never be needed'
dept. ask yourself how many times you had to killall -9 $something.
(not that killall is the right solution for zap!)

> - inetd begone! -> xinetd (better mechanism to control DoS, privilege
> separation, etc.)

IIRC a mechanism for *netd switching had been discussed in Woody times,
then waited for Sarge and I believe we already had some preliminary
implementation but it's still not finished. Other distros like PLD had
that years ago, btw.

> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=
=3D5

Do we really need that? I thought I could always
enable/disable/install/remove [xgk]dm. And are these runlevels mandated
(or at least documented) by any standard (besides 'the RH way')? Are
they at least consistent among ~"all distros besides Debian"?

> - Better package search mechanism (tags?) allowing free text search
> in package management interfaces: "I want a program that does X"

Doesn't 'apt-cache search X' do exactly that?

Cheers,

Grzegorz B. Prokopski
--=20
Grzegorz B. Prokopski <gadek@sablevm.org>
SableVM - Free, LGPL'ed Java VM http://sablevm.org
Why SableVM ?!? http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS http://www.debian.org

Frans Pop

2005-06-07, 2:49 am

David Goodenough

2005-06-07, 2:49 am

On Tuesday 07 June 2005 08:56, Frans Pop wrote:
> On Tuesday 07 June 2005 03:21, Joey Hess wrote:
Another item that might be worth considering for laptops is a networking
equivalent of the pmount group. People in these groups would be allowed
to edit the network files (in particular /etc/network/interfaces) and bring
interfaces up and down. Obviously on servers and corporate desktops
this group would be empty or contain only system admins, but on a
laptop you have to be able to fit into the network you are presented
with and you do not want joe-user to be switching to root all the time
just in order to do these functions.

I realise that this would require fixes to a number of packages, and quite
possibly some additional code to give a graphical interface to the
/etc/networking/interfaces file would be a good idea for GUI only users
and those who might not understand the consequences of incorrectly
coded entries and need a program to do it for them.

David[vbcol=seagreen]
>
> This sounds like a good idea, but will need very careful logic.
> For instance, some older (APM-based) Toshiba laptops work well with the
> toshiba module and the toshset package where newer (ACPI-based) laptops
> need the toshiba-acpi module which does not work with toshset.
> I would suspect that similar distinctions exist for other makes.
>
>
> One thing I feel is currently missing is to show users which tasks have
> been automatically selected and the option to deselect them (maybe only
> at medium or lower priority).
>
> Which brings me to another pet wish: make it a lot easier to install at
> medium priority than currently.
> IMO there is a real use for medium priority:
> - experienced users now often choose expert and get confused by some of
> the informational dialogs (especially the "unavailable drivers" one)
> - for users installing for the first time the "no dhcp" boot option and
> such are not really obvious, medium priority can be used to offer
> useful freedom in a structured way keeping expert for difficult hardware

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frans Pop

2005-06-07, 7:54 am

cobaco (aka Bart Cornelis)

2005-06-07, 7:54 am

On 2005-06-07 04:57, Grzegorz B. Prokopski wrote:
> On Tue, 2005-07-06 at 01:03 +0200, Javier Fern=E1ndez-Sanguino Pe=F1a wro=
te:
>
> Do we really need that? I thought I could always
> enable/disable/install/remove [xgk]dm. And are these runlevels mandated
> (or at least documented) by any standard (besides 'the RH way')? Are
> they at least consistent among ~"all distros besides Debian"?

If we're gonna change this, could we please use the LSB definition [1]?

[1]=20
http://refspecs.freestandards.org/L...LSB-Core-gener=
ic/runlevels.html
=2D-=20
Cheers, cobaco (aka Bart Cornelis)
=20
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)

Wouter Verhelst

2005-06-07, 7:54 am

On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote:
> On Jun 07, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
>
> In my wishlist there is NO support of 2.4 kernels, so modutils would
> become unneeded.
> 2.4.x kernels are already obsolete by now except that for some doorstop
> architectures, I do not know about any other modern distribution which
> still installs one.

Since (at least) potato, Debian has always supported more than one major
line of kernels. I don't see why we suddenly would need to change that
now.

I _do_ agree, however, that 2.2 should be dropped. This might mean
having to drop the mac subarch for m68k if the kernel isn't fixed by the
time etch releases, but then so be it.

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Steve Langasek

2005-06-07, 7:54 am

On Tue, Jun 07, 2005 at 11:12:50AM +0200, Wouter Verhelst wrote:
> On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote:
[vbcol=seagreen]
> Since (at least) potato, Debian has always supported more than one major
> line of kernels. I don't see why we suddenly would need to change that
> now.

We've done this out of necessity -- *not* because it's a good idea.

--
Steve Langasek
postmodern programmer

Cesar Martinez Izquierdo

2005-06-07, 7:54 am

What about switching from getty to mingetty? Is there any reason to use get=
ty=20
by default?

Regards,

C=E9sar

Thomas Hood

2005-06-07, 7:54 am

On Tue, 07 Jun 2005 01:10:15 +0200, Javier Fernández-Sanguino Peña
wrote:

> Ok, so sarge has been released! We should all thank the Release Team for
> their hard work in putting this major release together.

Yes. Thanks to everyone involved for the many, many hours they devoted to
getting sarge into shape.

> So, without further delay, here's my "Etch-wishlist", it's [based] on
> some of the things I've personally worked on and would like to keep
> working on for etch.

Debian needs to make a release plan. The plan should establish a target
release date for etch. Projects on the TODO-for-etch list must then be
projects that can be completed within the allotted time. A choice has to
be made early on whether to go for a short-term bugfix release or for a
longer-term restructuring release. Respective development times would be,
say, six months versus eighteen months. I hope that the DPL will get
involved in this debate and steer it toward a firm decision.

To begin with we can all go back and review:

http://wiki.debian.net/index.cgi?ReleaseProposals

--
Thomas Hood

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Thomas Hood

2005-06-07, 7:54 am

On Tue, 07 Jun 2005 10:10:13 +0200, David Goodenough wrote:
> Another item that might be worth considering for laptops is a networking
> equivalent of the pmount group. People in these groups would be allowed
> to edit the network files (in particular /etc/network/interfaces) and bring
> interfaces up and down.

http://people.redhat.com/dcbw/NetworkManager/

--
Thomas Hood

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

David Goodenough

2005-06-07, 7:54 am

On Tuesday 07 June 2005 09:26, Thomas Hood wrote:
> On Tue, 07 Jun 2005 10:10:13 +0200, David Goodenough wrote:
>
> http://people.redhat.com/dcbw/NetworkManager/
>
> --
> Thomas Hood
Reading the page at the URL I am a little unsure as to whether it requires
the user to have root access or knowledge of the root password, or if
the daemon simply does what the client code tells it to regardless.

I will download the code and see if I can make it work.

Has anyone made a DEB of it yet, apt-get.org could not find one.

David

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Christoph Hellwig

2005-06-07, 7:54 am

On Tue, Jun 07, 2005 at 12:04:26PM +0200, Wouter Verhelst wrote:
> Obviously. What I meant is, we shouldn't throw out "doorstop
> architectures" (sic) because they still want 2.4.

Which architecture do you refer to? All architectures supported by
debian are supported much better by 2.6 thn by 2.4, in fact none of
them is supported anymore upstream except for important bugfixes.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Wouter Verhelst

2005-06-07, 7:54 am

On Tue, Jun 07, 2005 at 02:18:47AM -0700, Steve Langasek wrote:
> On Tue, Jun 07, 2005 at 11:12:50AM +0200, Wouter Verhelst wrote:
>
>
> We've done this out of necessity -- *not* because it's a good idea.

Obviously. What I meant is, we shouldn't throw out "doorstop
architectures" (sic) because they still want 2.4. At least not with the
current state of affairs; by the time etch releases, I might have
changed my opinion on that subject.

The situation is different for 2.2; I don't want to see 2.2 in etch as
much as anyone else.

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

David Goodenough

2005-06-07, 7:54 am

On Tuesday 07 June 2005 09:26, Thomas Hood wrote:
> On Tue, 07 Jun 2005 10:10:13 +0200, David Goodenough wrote:
>
> http://people.redhat.com/dcbw/NetworkManager/
>
> --
> Thomas Hood
Having downloaded NetworkManager I see that there are two things that
I need that it does not do. Firstly it currently requires DHCP, and while
that is fine for networks I control, others may not have it and do I need
the ability to define static data which this does not give me.

Secondly as far as I can see currently this is integrated into GNOME, but
not KDE. While obviously I can run a GNOME app under KDE part of the
point of an app like this is its menu applet, and unless something changed
recently GNOME applets do not run under KDE.

However it may be a good starting point.

David

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marco d'Itri

2005-06-07, 7:54 am

On Jun 07, Wouter Verhelst <wouter@debian.org> wrote:

> Since (at least) potato, Debian has always supported more than one major
> line of kernels. I don't see why we suddenly would need to change that
> now.
We did it because of the need to support doorstops, not because it's a
good idea.
2.4 kernels are obsolete *now*, are not getting many new drivers and
the lack of sysfs and other features make some packages much more
complex than they should be.

--
ciao,
Marco

Olaf van der Spek

2005-06-07, 7:54 am

Javier Fernández-Sanguino Peña wrote:
> Ok, so sarge has been released! We should all thank the Release Team for
> their hard work in putting this major release together. But... how about we
> start discussing about what major release goals we want to set for Etch?

I'd like to see:
The ability to easily run multiple independent copies of a daemon. At
the moment you'd have to manually edit init scripts and conf scripts but
it'd be nice to see this automatically supported.

The ability to have multiple versions of a package installed at the same
time.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tollef Fog Heen

2005-06-07, 7:54 am

* Joey Hess

| Planned, and ground already laid in tasksel (and indeed, it does do it
| for some easy things like language tasks). One thing I really want to
| see happen is a laptop task. The big missing peice is some simple
| program tasksel can call out to, like
|
| if this_is_a_laptop; then
| ..
| fi

Look at the laptop-detect package in ubuntu. It should probably be
uploaded to Debian too, even though it's really simple (37 lines of
shell, it looks like).

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrew Suffield

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 10:23:33AM +0200, Thomas Hood wrote:
> To begin with we can all go back and review:
>
> http://wiki.debian.net/index.cgi?ReleaseProposals

I reviewed it and it still all falls into two groups:

- Hopelessly unworkable or silly ideas. ("Don't release", "Release no
matter how broken", "Do vastly more work than we currently fail to
do", "Replace Debian with Redhat^WMandrake^WGentoo^WUbuntu")

- Votes for more money ("Suck less", "Release better and more often")

So that was pretty useless.

The page itself is a good example of why things are the way they are,
though.

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Andrew Suffield

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> - inetd begone! -> xinetd (better mechanism to control DoS, privilege
> separation, etc.)

xinetd begone. There is no justification for using anything resembling
inetd on a modern system.

> - Better OS backup management -> upgrade rollback?

Selecting one of the many existing viable methods is pointless, as
most people will just have to get rid of it again before using
whatever they prefer. Creating a new one seems equally pointless. We
do not have a shortage of backup tools. If you have specific issues
with the particular tool you use, you know where to send them.

> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5

No way. Debian has always avoided mindlessly dictating what runlevels
must be used for. There's no reason to destroy this feature now. And
there's no advantage to consuming an entire runlevel just to say
"/etc/init.d/xdm stop" or "/etc/init.d/networking stop", which is
all that you are proposing.

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Roberto C. Sanchez

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 02:32:53PM +0100, Andrew Suffield wrote:
> On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
>
> xinetd begone. There is no justification for using anything resembling
> inetd on a modern system.
>
Why? What if I prefer to have something from inetd only when necessary
instead of constantly running daemons everywhere?

>
> Selecting one of the many existing viable methods is pointless, as
> most people will just have to get rid of it again before using
> whatever they prefer. Creating a new one seems equally pointless. We
> do not have a shortage of backup tools. If you have specific issues
> with the particular tool you use, you know where to send them.
>
I think he was referring to being able to rollback to an earlier version
of an installed package. Something which is currently not supported,
AIUI. Maybe even an earlier release of Debian.

>
> No way. Debian has always avoided mindlessly dictating what runlevels
> must be used for. There's no reason to destroy this feature now. And
> there's no advantage to consuming an entire runlevel just to say
> "/etc/init.d/xdm stop" or "/etc/init.d/networking stop", which is
> all that you are proposing.
>

I agree. I rather like being able to configure run levels to my liking.

-Roberto

--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr

Joey Hess

2005-06-07, 5:59 pm

Christoph Hellwig wrote:
> Which architecture do you refer to? All architectures supported by
> debian are supported much better by 2.6 thn by 2.4, in fact none of
> them is supported anymore upstream except for important bugfixes.

Be that as it may, my feeling from reading a great many installation
reports is that giving users the ability to try 2.4 if 2.6 fails to work
(or vice versa) saves a fair number of installs that otherwise wouldn't
be possible for various reasons. Better supported != perfectly supported
after all, and 2.6 certianly still contains some regressions from 2.4.

--
see shy jo

Joey Hess

2005-06-07, 5:59 pm

Frans Pop wrote:
> This sounds like a good idea, but will need very careful logic.
> For instance, some older (APM-based) Toshiba laptops work well with the
> toshiba module and the toshset package where newer (ACPI-based) laptops
> need the toshiba-acpi module which does not work with toshset.
> I would suspect that similar distinctions exist for other makes.

If installing both packages is a problem on some machines, we would need
to either fix the package to not do evil things on unsupported hardware,
or or have two tasks.

>
> One thing I feel is currently missing is to show users which tasks have
> been automatically selected and the option to deselect them (maybe only
> at medium or lower priority).

Tasksel supports this (not based on priority though); we just currently
hide the language tasks to keep the task list sane.

> Which brings me to another pet wish: make it a lot easier to install at
> medium priority than currently.
> IMO there is a real use for medium priority:
> - experienced users now often choose expert and get confused by some of
> the informational dialogs (especially the "unavailable drivers" one)
> - for users installing for the first time the "no dhcp" boot option and
> such are not really obvious, medium priority can be used to offer
> useful freedom in a structured way keeping expert for difficult hardware

I agree, except I'd just as soon see these changes apply to expert mode
installs.

--
see shy jo

Andrew Suffield

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 09:37:29AM -0400, Roberto C. Sanchez wrote:
> On Tue, Jun 07, 2005 at 02:32:53PM +0100, Andrew Suffield wrote:
> Why? What if I prefer to have something from inetd only when necessary
> instead of constantly running daemons everywhere?

Why on earth would you? It's just more administrative overhead, and
yet another package you didn't need.

> I think he was referring to being able to rollback to an earlier version
> of an installed package. Something which is currently not supported,
> AIUI. Maybe even an earlier release of Debian.

It's supported just fine if you take backups at the appropriate
moment. I can't think of any useful way in which it could be more
supported than that.

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Petter Reinholdtsen

2005-06-07, 5:59 pm

[Andrew Suffield]
> It's supported just fine if you take backups at the appropriate
> moment. I can't think of any useful way in which it could be more
> supported than that.

You should be careful when using your imagination as the guideline for
what is useful or not. It might not be a very accurate source of
information.

RPM got rollback support, and it is very useful. I recommend reading
some of the articles describing its support. For example
<URL:http://www.linuxjournal.com/article/7034> can be used to learn
more about this feature.

I wished dpkg supported a similar feature.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roberto C. Sanchez

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 08:03:31AM -0400, Joey Hess wrote:
> Frans Pop wrote:
>
> If installing both packages is a problem on some machines, we would need
> to either fix the package to not do evil things on unsupported hardware,
> or or have two tasks.
>

I am in favor of fixing the packages instead of complicating task
selection. From a user persective, task selection should be a no
brainer. The user, ideally, should not to be too concerned with whether
the laptop has APM, ACPI, or both.

I have already adopted toshutils and will be adopting/uploading toshset
next week with a new version that is supposed to (according to upstream)
handle both APM and ACPI variants. Let me know what I need to do.

-Roberto

--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr

Roberto C. Sanchez

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 02:40:48PM +0100, Andrew Suffield wrote:
> On Tue, Jun 07, 2005 at 09:37:29AM -0400, Roberto C. Sanchez wrote:
>
> Why on earth would you? It's just more administrative overhead, and
> yet another package you didn't need.
>
You can't really thank that in *every* case that is true. What if I or
another user in a situation where the administrative overhead is better
or more desirable than the overhead of having a daemon running in the
background all the time?

-Roberto

--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr

George Danchev

2005-06-07, 5:59 pm

On Tuesday 07 June 2005 16:25, Andrew Suffield wrote:
> On Tue, Jun 07, 2005 at 10:23:33AM +0200, Thomas Hood wrote:
>
> I reviewed it and it still all falls into two groups:
>
> - Hopelessly unworkable or silly ideas. ("Don't release", "Release no
> matter how broken", "Do vastly more work than we currently fail to
> do", "Replace Debian with Redhat^WMandrake^WGentoo^WUbuntu")
>
> - Votes for more money ("Suck less", "Release better and more often")
>
> So that was pretty useless.
>
> The page itself is a good example of why things are the way they are,
> though.

Would you please contribute your suggestions (either improve bits at that page
or somewhere else) of how to improve things. Thanks.

--
pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Remi Vanicat

2005-06-07, 5:59 pm

Andrew Suffield <asuffield@debian.org> writes:

> On Tue, Jun 07, 2005 at 09:37:29AM -0400, Roberto C. Sanchez wrote:
>
> Why on earth would you? It's just more administrative overhead, and
> yet another package you didn't need.

Because I've something else to do with my RAM than to run yet another
daemon that will be used at most every other month.

--
Rémi Vanicat

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Petri Latvala

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 11:40:55AM +0200, Olaf van der Spek wrote:
> The ability to have multiple versions of a package installed at the same
> time.

(Sorry Olaf, for getting this twice, my fingers work too fast)

No, dear $DEITY. This "feature" is the major thing I hate about
rpms. It's so easy to get wrong and install a package's new version
side-by-side when you meant to update the old one. And don't say "just
be careful" when there are people in the world who are not seasoned
sysadmin veterans who audit every init.d script and whatnot.

Making installing another version on the side as a
--force-this-I-really-want-to-kick-myself option would not be as bad,
but still as bad. This just won't work. Both versions supply
$PATH/$FILE, and then what?

1) divert the other? what's the use of another package version then

2) install to another dir / another name of the file? Again, what's
the use

3) this is a library so it only has a .so file with another soname so
no name clashes. Hey, oops, different library soname already means a
different package (this, I think, is the reason why rpm supports
multiple versions)

--
Petri Latvala

Adrian von Bidder

2005-06-07, 5:59 pm

Adrian von Bidder

2005-06-07, 5:59 pm

Bernhard R. Link

2005-06-07, 5:59 pm

* Petter Reinholdtsen <pere@hungry.com> [050607 16:00]:
> You should be careful when using your imagination as the guideline for
> what is useful or not. It might not be a very accurate source of
> information.
>
> RPM got rollback support, and it is very useful. I recommend reading
> some of the articles describing its support. For example
> <URL:http://www.linuxjournal.com/article/7034> can be used to learn
> more about this feature.
>
> I wished dpkg supported a similar feature.

When I understand this correctly, this is more of a feature for apt or
even some higher level tool, to make sure you can those packages again
or repack them.

But the problem is that for this to work this way, you have to support
downgrades. With a more complex scheme supporting redowngrades (i.e.
upgrading and downgrading again when no user-made changes were done)
would be needed.
This has to be supported on a per package level in order to work. Many
packages are boring enough a normal downgrade will work, but there are
enough cases like databases to be converted to a new format or even
only some reodering of some symlinks, that are not trivially revertable.
(As changes do not need to be really injective, it might even be
theoreticaly impossible to do a downgrade). Supporting redowngrading
might be easier, as only all changed files have to be saved somehow
and be reapplied in a correct way.

But it currently is already hard to make sure upgrading works correctly
and with all older versions that can realistically be supported.
Testing and thinking of all those things needed to (re)downgrade is
even harder. Especially if one also wants to support rolling back
because some total-system-upgrade from one distribution to another has
to be supported. (If we knew all possibilities such a thing could break,
we would already cause it not to break upgrading, so how can this
realistically been tested?).

Which in my eyes yields to the reason this is not and most likely will
not be implemented: If you need the ability to fast roll-back upgrades,
you need to make an backup of everything poosibly changed (which easily
means a full backup), because noone will be so insane to guarantee you
it will work otherwise, no matter how much labor is but in there.
And if you have to do such a backup anyway, why put work in other
mechanisms, when the backup already supports a full, secure roll-back?

Hochachtungsvoll,
Bernhard R. Link

--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

John Hasler

2005-06-07, 5:59 pm

Andrew Suffield wrote:
> No way. Debian has always avoided mindlessly dictating what runlevels
> must be used for. There's no reason to destroy this feature now. And
> there's no advantage to consuming an entire runlevel just to say
> "/etc/init.d/xdm stop" or "/etc/init.d/networking stop", which is all
> that you are proposing.

Roberto C. Sanchez writes:
> I agree. I rather like being able to configure run levels to my liking.

Why would defaulting to something other than the current flat arrangement
prevent you from configuring your runlevels to your liking?
--
John Hasler

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Javier Fernández-Sanguino Peña

2005-06-07, 5:59 pm

On Mon, Jun 06, 2005 at 10:57:50PM -0400, Grzegorz B. Prokopski wrote:
> My impression was that firewall setting is generally a messy business,
> because there's too many packages that mess with it, usually assuming
> they're the only ones who touch it. This was, I think part of the
> reason why /etc/init.d/iptables was removed (I still use it on all of
> my old and newly installed machines, btw.) But maybe I am wrong and
> somebody else could provides more details here.

Actually, that's not why iptables's init script was removed. Firewall
packages (shorewall, bastille, knetfilter, guarddog, etc.) provide their
own firewall handling code, they don't use the 'iptables save'
functionality the iptables maintainer provided in previous releases.

In any case, no sysadmin should install conflicting firewalling code. I was
considering asking debian-policy to add a 'firewall' virtual package so
that all firewall packages Provided: it and Conflicted: with it.

>
> IIRC a mechanism for *netd switching had been discussed in Woody times,
> then waited for Sarge and I believe we already had some preliminary
> implementation but it's still not finished. Other distros like PLD had
> that years ago, btw.

There's preliminary implementation for the switch but the management tools
(i.e. netbase's update-inetd IIRC) need to be handle xinetd too (see
#8927, #10059 and #25816).

>
> Do we really need that? I thought I could always

Yes, IMHO we should use the LSB levels.

>
> Doesn't 'apt-cache search X' do exactly that?

No, it does not cut it. I will answer this in depth in a separate e-mail.

Regards

Javier

Marco d'Itri

2005-06-07, 5:59 pm

On Jun 07, Adrian von Bidder <avbidder@fortytwo.ch> wrote:

> Hmm. I've never verified this myself, however until recently it was often
> claimed that 2.6 is still quite a bit worse than 2.4 for some workloads -
This does not make it true.

> Wasn't that exactly what Javier proposed? Or is xinetd not sensible enough?
xinetd lacks /etc/inetd.conf. But I was merely pointing out that you do
not need to resort to xinetd to escape the netkit-inetd brokeness.

--
ciao,
Marco

Zack Cerza

2005-06-07, 5:59 pm

On 2005 June 07 Tuesday 06:04, David Goodenough wrote:
> On Tuesday 07 June 2005 09:26, Thomas Hood wrote:
>
> Reading the page at the URL I am a little unsure as to whether it requires
> the user to have root access or knowledge of the root password, or if
> the daemon simply does what the client code tells it to regardless.

=46rom my understanding, it just uses dbus. There was a dbus article[0] in =
Red=20
Hat Magazine in January that has a little information on dbus' handling of=
=20
NetworkManager security.

> I will download the code and see if I can make it work.

I'd be interested in hearing about any issues you encounter when trying to=
=20
make this work on Debian.

> Has anyone made a DEB of it yet, apt-get.org could not find one.

I started to, because there was a stretch where I actually had a laptop to =
use=20
(a loaner from work), but then the laptop went away and I didn't want to=20
maintain a package I couldn't really test ;)

NetworkManager has changed a lot since then, so anyone who wants to package=
it=20
at this point would probably be better off starting from scratch.

[0] http://www.redhat.com/magazine/003j.../dbus/#security

Zack

Javier Fernández-Sanguino Peña

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 09:33:02AM +0200, cobaco (aka Bart Cornelis) wrote:
> If we're gonna change this, could we please use the LSB definition [1]?
>
> [1]
> http://refspecs.freestandards.org/L.../runlevels.html

Sure, that's my goal, but my notes were taken based on my non-LSB-compliant
brain.

:-)

Javier

Meelis Roos

2005-06-07, 5:59 pm

JFSP> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5

Why? Display manager as a normal service that can be started and stopped
like other services is very natural. No need to confuse the users with
more runlevels since there's not much point in differentiating them
nowadays.

--
Meelis Roos (mroos@linux.ee)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Meelis Roos

2005-06-07, 5:59 pm

JFSP> - inetd begone! -> xinetd (better mechanism to control DoS, privilege
JFSP> separation, etc.)

Privilege separation etc is nice, but have a look at xinetd source and
reconsider. I have tried to fix a DoS-like problem (a timing-related bug
that caused temporary disabling of services) in xinetd once but
eventually gave up. The code is IMHO unmaintainable and doesn't raise
much trust.

If a replacement is needed, I would rather look at openbsd-inetd.

--
Meelis Roos (mroos@linux.ee)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Zack Cerza

2005-06-07, 5:59 pm

On 2005 June 07 Tuesday 06:09, David Goodenough wrote:
> On Tuesday 07 June 2005 09:26, Thomas Hood wrote:
>
> Having downloaded NetworkManager I see that there are two things that
> I need that it does not do. Firstly it currently requires DHCP, and while
> that is fine for networks I control, others may not have it and do I need
> the ability to define static data which this does not give me.

Well, NetworkManager needs backends for each distro to parse their config
files - on RH/Fedora systems it uses /etc/sysconfig/network-scripts/ifcfg-*,
which might just map to /etc/network/interfaces on Debian. Apparently
NetworkManager just uses those settings, for the most part. If you have an
interface set up to use static IPs it should just work.

Dan isn't sure what the state of the Debian backend is, but he mentioned that
Tom Parker has submitted some Debian-related patches for NM in the past.

> Secondly as far as I can see currently this is integrated into GNOME, but
> not KDE. While obviously I can run a GNOME app under KDE part of the
> point of an app like this is its menu applet, and unless something changed
> recently GNOME applets do not run under KDE.

I've had conversations with Dan about this. He's told me that it would be
"entirely possible" to create a KDE frontend to the NetworkManager core.
NetworkManager itself (not the applet, just the daemon) only requires hal,
dbus and glib. Back in February a KDE developer expressed interest in doing
this, but nothing seems to have materialized. In any case, Dan has offered
his help "with any questions or architectural stuff if needed".

The applet itself, he says, might be difficult as it uses two threads - one
for dbus calls, and one for the animation.

I've wanted to play around with it, too, but... yeah, the laptop thing.

Zack

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrew Suffield

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 05:06:45PM +0300, George Danchev wrote:
> On Tuesday 07 June 2005 16:25, Andrew Suffield wrote:
>
> Would you please contribute your suggestions (either improve bits at thatpage
> or somewhere else) of how to improve things. Thanks.

What makes you think I have any?

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Andrew Suffield

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 03:58:52PM +0200, Petter Reinholdtsen wrote:
> [Andrew Suffield]
>
> You should be careful when using your imagination as the guideline for
> what is useful or not. It might not be a very accurate source of
> information.
>
> RPM got rollback support, and it is very useful. I recommend reading
> some of the articles describing its support. For example
> <URL:http://www.linuxjournal.com/article/7034> can be used to learn
> more about this feature.
>
> I wished dpkg supported a similar feature.

Somebody else already explained why it's impractical for both dpkg and
rpm, so I'll just note that you're changing the subject.

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Andrew Suffield

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 10:06:55AM -0400, Roberto C. Sanchez wrote:
> On Tue, Jun 07, 2005 at 02:40:48PM +0100, Andrew Suffield wrote:
> You can't really thank that in *every* case that is true. What if I or
> another user in a situation where the administrative overhead is better
> or more desirable than the overhead of having a daemon running in the
> background all the time?

Then you can go install xinetd, just like all sorts of other weird
shit. Oh look, you can *already* do that.

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Will Newton

2005-06-07, 5:59 pm

On Tuesday 07 June 2005 20:16, Andrew Suffield wrote:

>
> What makes you think I have any?

A lack of familiarity with your posts?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrew Suffield

2005-06-07, 5:59 pm

On Tue, Jun 07, 2005 at 04:19:19PM +0200, Remi Vanicat wrote:
> Andrew Suffield <asuffield@debian.org> writes:
>
>
> Because I've something else to do with my RAM than to run yet another
> daemon that will be used at most every other month.

Disk space, not RAM. You lose *real* RAM by running inetd, and this is
premature optimisation anyway. Have you actually measured how much
physical memory the stuff you run consumes running as both inetd and
proper daemons, and determined that the difference would result in a
noticable improvement? Hint: it's a very small and sometimes slightly
negative amount.

My bet is that you just read in a book somewhere that inetd uses less
memory, and forgot to check the date on the book. inetd is a throwback
to the 1980s.

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Brendan

2005-06-07, 6:00 pm

On Tuesday 07 June 2005 09:37 am, Roberto C. Sanchez wrote:
> I agree. I rather like being able to configure run levels to my liking.

I'm sorry, but this sets off my "Give me a break" reaction...
There's nothing wrong with a "By Default, this runlevel is this...but you can
change it if you wish"...You'll be getting rid of an easy-to-remember key
that helps many newbies remember what the heck is going on "Oh, /etc/inittab
says I start up in 3, that must mean it's multi-user with no GUI".
To leave it up in the air so that a few people can dork out and define their
own (yes, I'm kidding...but only a little) seems a bit like throwing over
some ease-of-use for dorkin' it hardcore.

I mean, it's not up to me, but if it was, I would have some easy-to-remember
guidelines like
"3 is multi-user with no X" "5 is full gui, etc."
Remember, init 0 and 6 are well-defined already....

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roger Leigh

2005-06-07, 6:00 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Javier Fern=C3=A1ndez-Sanguino Pe=C3=B1a <jfs@computer.org> writes:

> Feel free to add some new items or add (hopefully new) information to the=
=20
> ones I list below:

[Transition to UTF-8 locales]
- - The locale codeset should be UTF-8 for all new installs by default.
- - Existing installations should be unaffected, but it might be nice to
offer to generate the equivalent UTF-8 locales for the locales in use.
- - When UTF-8 is the default locale, it shouldn't need a .UTF-8 suffix,
e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 (the
opposite way round to the current situation which creates
en_GB.UTF-8 and en_GB [Latin-1]).

This change has (as far as I can tell) been done already by most major
commercial distributions (e.g. SuSE, RedHat). The actual mechanics of
the transition should be fairly straightforward, since UTF-8 locales
are already supported, this is simply switching the defaults in the
locales package. This won't affect existing installs, so breakage
should be none to minimal.

At a later point, we should also look into recoding our documentation
into UTF-8. While reviewing RC bugs for sarge, I found that the
DocBook toolchain is quite broken WRT text encoding support. It
doesn't put the encoding in the generated HTML, which nowadays is not
acceptable. See gnupg-doc for examples.

Regards,
Roger

- --=20
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your m=
ail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCpf8qVcFcaSW/ uEgRArXjAKDdfCkwr+mPzTrZ868BLhseYZBrBACg
rlsF
p131Thi/tFD6l21V0ttqMqs=3D
=3Du6JO
-----END PGP SIGNATURE-----

Frans Pop

2005-06-07, 6:00 pm

Tollef Fog Heen

2005-06-07, 6:00 pm

* Roger Leigh

| - When UTF-8 is the default locale, it shouldn't need a .UTF-8 suffix,
| e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 (the
| opposite way round to the current situation which creates
| en_GB.UTF-8 and en_GB [Latin-1]).

Eh? You can't change that around just like that, it will break in the
cases where people ssh in from machines with latin1 locales for
instance (and use the PassEnv feature of newer SSHs). To me, it looks
like you can't ever change the charset of a locale once it is created.

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roger Leigh

2005-06-07, 6:00 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frans Pop <aragorn@tiscali.nl> writes:

> On Tuesday 07 June 2005 22:10, Roger Leigh wrote:
>
> This looks to be a contradiction.
> If you make UTF-8 default and remove the suffix for UTF-8 usage, won't
> existing installs that have LANG=en_GB in their /etc/environment be very
> much affected?

Existing installs are already configured with debconf. Their
/etc/locale.gen will not be touched.

If you do dpkg-reconfigure locales, then users could have the locale
switch to UTF-8 if they so choose. The system should then carry on
working like normal, except for the fact that they are now using the
UCS.

There is potential for breakage if they have any software that does
not behave correctly in a UTF-8 locale. IMO we should treat such
packages as being seriously buggy, and get them fixed or removed.
Nowadays, there should be few pieces of software that break this way,
and there is really no excuse for it.

Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCpgtjVcFcaSW/uEgRAjhTAJ9M88ZCAnn0y8Jiu72o/FjXzhZygQCeNCj3
3VI05CfJlqFl04kWuH9QxAk=
=Dp6t
-----END PGP SIGNATURE-----

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frans Pop

2005-06-07, 6:00 pm

Roger Leigh

2005-06-07, 6:00 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frans Pop <aragorn@tiscali.nl> writes:

> On Tuesday 07 June 2005 23:02, Roger Leigh wrote:
>
> AFAIK locales are automatically regenerated when the locales package is
> upgraded, so this _would_ effect every existing install directly on
> upgrade to the new release.

locale-gen is run, but /etc/locale.gen is not necessarily altered. If
you don't change it, it will regenerate the same locales you already
have.

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCphJnVcFcaSW/ uEgRAo2hAJ48AnTc2UPfaT8maeMOYuBV1rPT2wCc
DAEk
tVJEz0PvV79FVZ9tPsqQZv0=
=AUNx
-----END PGP SIGNATURE-----

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roger Leigh

2005-06-07, 6:00 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tollef Fog Heen <tfheen@err.no> writes:

> * Roger Leigh
>
> | - When UTF-8 is the default locale, it shouldn't need a .UTF-8 suffix,
> | e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 (the
> | opposite way round to the current situation which creates
> | en_GB.UTF-8 and en_GB [Latin-1]).
>
> Eh? You can't change that around just like that, it will break in the
> cases where people ssh in from machines with latin1 locales for
> instance (and use the PassEnv feature of newer SSHs).

IMHO if you want features like that to work, you should be fully
qualifying your locale. en_GB on its own has always meant "British
English", in whatever locale the system administrator set as the
default, and the same applies to all unqualified locales. Sure, ssh
might not work, but it /never has/, except by coincidence where two
systems had the same locale setup.

I've used UTF-8 default locales for several years now, i.e.
[/etc/locale.gen]
en_GB UTF-8

> To me, it looks like you can't ever change the charset of a locale
> once it is created.

I don't agree. For the last three years, I've created them the "new
way", in contradiction to the default. Nowhere is it defined what the
existing unqualified locale names mean, save in the defaults, so there
are no guarantees here: they could have been set to /anything/.

Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCphGCVcFcaSW/ uEgRAhrWAJ9A7bJUUvPXhFBMwy5t8AYCWOiJFQCg
9fs1
N6b7o4vasTzKoJBAVOVgLUY=
=hMs9
-----END PGP SIGNATURE-----

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roberto C. Sanchez

2005-06-07, 6:00 pm

On Tue, Jun 07, 2005 at 03:51:46PM -0400, Brendan wrote:
> On Tuesday 07 June 2005 09:37 am, Roberto C. Sanchez wrote:
>
> I'm sorry, but this sets off my "Give me a break" reaction...
> There's nothing wrong with a "By Default, this runlevel is this...but youcan
> change it if you wish"...You'll be getting rid of an easy-to-remember key
> that helps many newbies remember what the heck is going on "Oh, /etc/inittab
> says I start up in 3, that must mean it's multi-user with no GUI".
> To leave it up in the air so that a few people can dork out and define their
> own (yes, I'm kidding...but only a little) seems a bit like throwing over
> some ease-of-use for dorkin' it hardcore.
>
> I mean, it's not up to me, but if it was, I would have some easy-to-remember
> guidelines like
> "3 is multi-user with no X" "5 is full gui, etc."
> Remember, init 0 and 6 are well-defined already....

OK. Where, pray tell, is a newbie going to learn about that? Most
newbies that come from MS Windows and Mac OS understand three modes of a
computer, to us run levels 0, 6 and {2,3,4,5}. Personally, I think it
is much more newbie friendly to have run levels 2-5 be the same. It is
also more expert friendly since you can tweak to your heart's content.

-Roberto

--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr

Tollef Fog Heen

2005-06-07, 6:00 pm

* Roger Leigh

| Tollef Fog Heen <tfheen@err.no> writes:
|
| > * Roger Leigh
| >
| > | - When UTF-8 is the default locale, it shouldn't need a .UTF-8 suffix,
| > | e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 (the
| > | opposite way round to the current situation which creates
| > | en_GB.UTF-8 and en_GB [Latin-1]).
| >
| > Eh? You can't change that around just like that, it will break in the
| > cases where people ssh in from machines with latin1 locales for
| > instance (and use the PassEnv feature of newer SSHs).
|
| IMHO if you want features like that to work, you should be fully
| qualifying your locale. en_GB on its own has always meant "British
| English", in whatever locale the system administrator set as the
| default, and the same applies to all unqualified locales.

No, it haven't. Read /usr/share/i18n/SUPPORTED which is what locales
are supported in what locale from glibc.

| I've used UTF-8 default locales for several years now, i.e.
| [/etc/locale.gen]
| en_GB UTF-8

That gives you undefined behaviour which may or may not work (by
accident).

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

John Hasler

2005-06-07, 6:00 pm

Meelis Roos writes:
> Display manager as a normal service that can be started and stopped like
> other services is very natural. No need to confuse the users with more
> runlevels since there's not much point in differentiating them nowadays.

Users coming from other distributions expect more runlevels. It's the
_lack_ that confuses them.
--
John Hasler

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Colin Watson

2005-06-07, 6:00 pm

On Tue, Jun 07, 2005 at 10:28:37PM +0100, Roger Leigh wrote:
> Tollef Fog Heen <tfheen@err.no> writes:
>
> IMHO if you want features like that to work, you should be fully
> qualifying your locale.

en_GB.ISO-8859-1 doesn't exist unless you go to the effort of defining
it yourself - it's not in /usr/share/i18n/SUPPORTED. (Yes, in this case
there happens to be an ISO-8859-15 equivalent, but that's not the case
everywhere.)

I'm fairly sure I remember glibc upstream vowing never to change the
meaning of existing locales. Certainly this post from a locale hacker
well-known in these parts comes to mind:

http://lists.debian.org/debian-i18n...0/msg00075.html

> I've used UTF-8 default locales for several years now, i.e.
> [/etc/locale.gen]
> en_GB UTF-8

OpenSSH's SendEnv is a useful feature when applied to locales; it works
for many people and fixes an old bug. I'd hate to break it just as it's
started to work.

>
> I don't agree. For the last three years, I've created them the "new
> way", in contradiction to the default. Nowhere is it defined what the
> existing unqualified locale names mean, save in the defaults,

/usr/share/i18n/SUPPORTED is a little more than "the defaults", I think.
It's at least standard across systems that use glibc (in that you may
get additional entries, but you won't get different entries). This makes
up sufficiently many systems to make me pay attention.

Cheers,

--
Colin Watson [cjwatson@debian.org]

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bartosz Fenski aka fEnIo

2005-06-07, 6:00 pm

On Tue, Jun 07, 2005 at 05:55:00PM -0400, Roberto C. Sanchez wrote:
>
> OK. Where, pray tell, is a newbie going to learn about that? Most
> newbies that come from MS Windows and Mac OS understand three modes of a
> computer, to us run levels 0, 6 and {2,3,4,5}. Personally, I think it
> is much more newbie friendly to have run levels 2-5 be the same. It is
> also more expert friendly since you can tweak to your heart's content.

Newbie caming from MS Windows knows nothing about runlevels. The problem
are users caming from other distros. They used more runlevels almost for
sure, although they probably still don't know about it cause their newbies
right? ;)

regards
fEnIo

--
,''`. Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
: :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
`. `' phone:+48602383548 | proud Debian maintainer and user
`- http://skawina.eu.org | jid:fenio@jabber.org | rlu:172001

Thaddeus H. Black

2005-06-07, 6:00 pm

Roger Leigh:

> At a later point, we should also look into recoding
> our documentation into UTF-8.

Insofar as our documentation has upper-plane Latin-1 (or
terminal-shift) characters embedded, this is sensible.
However, we need to continue to think carefully about
this. We are going to support Unicode because we have
no practical alternative. However, Unicode is a bad
standard. It is highly overwrought. Its philosophy is
wrong. Its use complicates many things which do not
need complication. Insofar as it contaminates clean
ascii in Debian source code and English-language
documentation, it is not a good thing.

Past character-set discussions on debian-devel have
established that many of the eastern European DDs feel
strongly about spelling their own Roman-alphabet names
without compromising with Latin-1. Consensus was that
we should respectfully support this and other sensible
uses of Unicode, and I agree with the consensus.

However, past character-set discussions on debian-devel
have also established how maddening it is to see a '-'
in a man page, unsearchable because it is not really a
'-'; it is an en-dash or a minus or an Inuit glottal
stop or something else you can't distinguish and can't
type. It has also been observed (by me at least) that
Unicode vastly complicates or altogether breaks rational
assumptions about how a simple printf() will display on
the terminal. If I lose the easy ability to make a
column of ':' line neatly up in column 25 of the
terminal, while gaining the ability to display Nepalese
subjoined circumflexes and the International Phonetic
Alphabet bidirectionally, this is probably not a win for
me.

Now, I do have some ideas as to what Debian can do about
this. If you prod me, I am not unlikely to begin to
post them now. Otherwise, not wanting to weigh the
release party down with such heavy discussions, I would
save them for a later thread of their own, perhaps after
a month or two.

--
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, t@b-tk.org, thb@debian.org

Olaf van der Spek

2005-06-07, 8:49 pm

Petri Latvala wrote:
> On Tue, Jun 07, 2005 at 11:40:55AM +0200, Olaf van der Spek wrote:
>
>
>
> (Sorry Olaf, for getting this twice, my fingers work too fast)
>
> No, dear $DEITY. This "feature" is the major thing I hate about
> rpms. It's so easy to get wrong and install a package's new version
> side-by-side when you meant to update the old one. And don't say "just
> be careful" when there are people in the world who are not seasoned
> sysadmin veterans who audit every init.d script and whatnot.
>
> Making installing another version on the side as a
> --force-this-I-really-want-to-kick-myself option would not be as bad,
> but still as bad. This just won't work. Both versions supply
> $PATH/$FILE, and then what?

Supporting side-by-side file installation isn't (that) simple. But that
doesn't mean it wouldn't be useful.
A mechanism would be needed to specify which version of an application
should be run. Should this be system-wide, per-user, per-environment?

> 1) divert the other? what's the use of another package version then

That depends on system-wide vs per-user vs per-environment.

> 2) install to another dir / another name of the file? Again, what's
> the use
>
> 3) this is a library so it only has a .so file with another soname so
> no name clashes. Hey, oops, different library soname already means a
> different package (this, I think, is the reason why rpm supports
> multiple versions)

Does it?
I thought minor updates didn't change soname?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

John Hasler

2005-06-07, 8:49 pm

Roberto C. Sanchez writes:
> Where, pray tell, is a newbie going to learn about [runlevels]?

a) By having used Red Hat.
b) By reading up on Linux before trying to use it (yes, some people _do_
that).

--
John Hasler

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Brendan

2005-06-07, 8:49 pm

On Tuesday 07 June 2005 09:23 pm, Roberto C. Sanchez wrote:
> On Tue, Jun 07, 2005 at 09:20:56PM -0400, Brendan wrote:
>
> Point taken. I was thinking of how I came to Debian (from Windows
> without reading a lick of documentation). If you don't believe me,
> check out my postings from late '02 to earl '03 on d-u. I sound like a
> total lamer :-)

I am one of (maybe) the few people who has a Debian distro with a compiled KDE
CVS on top of it, so I need some flexibility. I like booting to init 3 and
having that always mean that it's just missing the startx command
with /usr/local/kde/bin/startkde in it...
I like to make sure my Mom is always running init5. Beyond those two, and 0
and 6, the rest I couldn't give a rat's a about run levels honestly.

B

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Brendan

2005-06-07, 8:49 pm

On Tuesday 07 June 2005 07:09 pm, John Hasler wrote:
> Roberto C. Sanchez writes:
>
> a) By having used Red Hat.
> b) By reading up on Linux before trying to use it (yes, some people _do_
> that).

I couldn't have said it better.
Roberto, what John said.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roberto C. Sanchez

2005-06-07, 8:49 pm

On Tue, Jun 07, 2005 at 09:20:56PM -0400, Brendan wrote:
> On Tuesday 07 June 2005 07:09 pm, John Hasler wrote:
>
> I couldn't have said it better.
> Roberto, what John said.

Point taken. I was thinking of how I came to Debian (from Windows
without reading a lick of documentation). If you don't believe me,
check out my postings from late '02 to earl '03 on d-u. I sound like a
total lamer :-)

-Roberto

--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr

Miles Bader

2005-06-07, 8:49 pm

Will Newton <will@misconception.org.uk> writes:
>
> A lack of familiarity with your posts?

Not fair; asuffield is often needlessly inflammatory, but he's posted
plenty of useful and insightful stuff.

-Miles
--
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Miles Bader

2005-06-07, 8:49 pm

"Bernhard R. Link" <brlink@debian.org> writes:
> But the problem is that for this to work this way, you have to support
> downgrades. With a more complex scheme supporting redowngrades (i.e.
> upgrading and downgrading again when no user-made changes were done)
> would be needed.
> This has to be supported on a per package level in order to work. Many
> packages are boring enough a normal downgrade will work, but there are
> enough cases like databases to be converted to a new format or even
> only some reodering of some symlinks, that are not trivially revertable.

I always assumed that if downgrading didn't work, it was a bug; is this
not true?

-Miles
--
Occam's razor split hairs so well, I bought the whole argument!

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Don Armstrong

2005-06-08, 2:49 am

On Tue, 07 Jun 2005, Olaf van der Spek wrote:
> Petri Latvala wrote:
>
> That depends on system-wide vs per-user vs per-environment.

If you want something done per-user/per-environment, you can always
use dpkg-deb -x foo.deb .; or whatever to unpack the version you want
to run manually.

Alternatively, you can have a chroot with the strange versions that
you want.

Having multiple versions system wide when you haven't explicitly
planned for multple versions is just asking for madness. It's
especially insane when there are already reasonable methods for having
multiple versions of things installed when that is a reasonable thing
to do. (Think libfoo2, autoconf2.13 or similar.)

Don Armstrong

--
"For those who understand, no explanation is necessary.
For those who do not, none is possible."

http://www.donarmstrong.com http://rzlab.ucr.edu

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

David Starner

2005-06-08, 2:49 am

"Thaddeus H. Black" writes:
> We are going to support Unicode because we have
> no practical alternative. However, Unicode is a bad
> standard. It is highly overwrought. Its philosophy is
> wrong. Its use complicates many things which do not
> need complication.=20

Lots of accusations but no backup.

> Insofar as it contaminates clean
> ascii in Debian source code and English-language
> documentation, it is not a good thing.

It doesn't change anything in source code; source code is still
ASCII. As for documentation, it's no different from any other=20
English language document. ASCII does not suffice for good=20
English, which has angled quotes and different lengths of dashes,=20
which was recognized by TeX, for a old school computer example.

> However, past character-set discussions on debian-devel
> have also established how maddening it is to see a '-'
> in a man page, unsearchable because it is not really a
> '-';

The simple fact is, there is a variety of dashes used in proper=20
English printing, and any universal character set is going to=20
have to deal with that. You can turn off this feature in man with=20
a one line change in a config file, and Debian could make it the=20
default; or programs that let you search text could merge
the various dashes at the same time they're merging cases.

> Unicode vastly complicates or altogether breaks rational
> assumptions about how a simple printf() will display on
> the terminal.

Assuming that bytes and columns are equivalent is irrational.
It is impossible to satisfy, given that there are thousands of=20
characters that historically have fit in one column or logically
should.

> If I lose the easy ability to make a
> column of ':' line neatly up in column 25 of the
> terminal,

It's called wcwidth.

> while gaining the ability to display Nepalese
> subjoined circumflexes and the International Phonetic
> Alphabet bidirectionally, this is probably not a win for
> me.

One system that supports everyone is a win for Debian
and the rest of the world.

Alban Browaeys

2005-06-08, 2:49 am

Le Tue, 07 Jun 2005 23:20:37 +0100, Colin Watson a écrit :

> en_GB.ISO-8859-1 doesn't exist unless you go to the effort of defining
> it yourself - it's not in /usr/share/i18n/SUPPORTED. (Yes, in this case
> there happens to be an ISO-8859-15 equivalent, but that's not the case
> everywhere.)

ahem ... /etc/locale.alias /etc/locale.gen
and /usr/X11R6/lib/X11/locale/locale.alias ...

legacy names includes the charset whatever it is ...

Well it does not help with ssh :-/

Regards
Alban

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Benjamin Mesing

2005-06-08, 2:49 am

On Tue, 2005-06-07 at 19:30 +0300, Meelis Roos wrote:
> JFSP> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5
>
> Why? Display manager as a normal service that can be started and stopped
> like other services is very natural. No need to confuse the users with
> more runlevels since there's not much point in differentiating them
> nowadays.
Two points come to my mind.
1. in case your X-Config is broken booting in runlevel 3 offers a
nice way to fix this
2. it is defined in the LSB

Greetings Ben

--
Please do not sent any email to the ben-ml@gmx.net - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bob Proulx

2005-06-08, 2:49 am

Benjamin Mesing wrote:
> Meelis Roos wrote:
> Two points come to my mind.
> 1. in case your X-Config is broken booting in runlevel 3 offers a
> nice way to fix this

How will switching to run level 3 fix this problem? Your X config is
still broken.

If your X configuration is broken and your X won't start then that is
effectively the same thing as the proposed run level 3 anyway. So
what is the point?

> 2. it is defined in the LSB

Can't argue with that.

Bob

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ian Campbell

2005-06-08, 2:49 am

On Wed, 2005-06-08 at 07:54 +0200, Benjamin Mesing wrote:
> On Tue, 2005-06-07 at 19:30 +0300, Meelis Roos wrote:
> Two points come to my mind.
> 1. in case your X-Config is broken booting in runlevel 3 offers a
> nice way to fix this

Debian already has a nice way to fix this -- if X doesn't start it tries
a couple of times and then disables itself and offers to show you the
log or drop you to a login prompt.

I don't know if this functionality is from the X packages or from gdm
etc. but it is a much better solution than the band aid offered by
run-levels...

Ian.
--
Ian Campbell

Ignorance is when you don't know anything and somebody finds it out.

Tollef Fog Heen

2005-06-08, 2:49 am

* Miles Bader

| I always assumed that if downgrading didn't work, it was a bug; is this
| not true?

Downgrades are not and have not been supported.

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marco d'Itri

2005-06-08, 7:48 am

On Jun 07, Roger Leigh <rleigh@whinlatter.ukfsn.org> wrote:

> - - The locale codeset should be UTF-8 for all new installs by default.
FFS! When will people learn to not mess with other cultures they know
nothing about?
Feel free to advocate a different default charset for *your* locale, but
do not pretend to know what's better for other locales.

--
ciao,
Marco

Jesus Climent

2005-06-08, 7:48 am

On Tue, Jun 07, 2005 at 01:28:13PM +0200, Marco d'Itri wrote:
>
> 2.4 kernels are obsolete *now*, are not getting many new drivers and
> the lack of sysfs and other features make some packages much more
> complex than they should be.

That does not make them obsolete. They are in maintenance mode, with security
updates being applied.

>From your definition of obsolete, Woody was obsolete for a very long time, and
yet it was updated with security fixes, which made it usable for many people.

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

Wait Master, it might be dangerous... you go first.
--Igor (Young Frankenstein)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jesus Climent

2005-06-08, 7:48 am

On Mon, Jun 06, 2005 at 09:21:37PM -0400, Joey Hess wrote:
> This solves your problem fairly well, since the issue then becomes only
> keeping d-i secure and keeping the installed system secure, not keeping
> the system secure while it's installing itself. Daemons will not be
> started dueing the installation, and will come up on reboot.

Add to the list of daemon related features the "not start daemons by default"
and wait for the admin to define which ones to start from /etc/defaults or
whatever.

I do _not_ want a web server right after apt-get installing it, since
everybody has to move the default page and create their own content.

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

It's a soldier's duty. You wouldn't understand.
--The Colonel (Akira)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jesus Climent

2005-06-08, 7:48 am

On Tue, Jun 07, 2005 at 02:32:53PM +0100, Andrew Suffield wrote:
> On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
>
> xinetd begone. There is no justification for using anything resembling
> inetd on a modern system.

Easy setting of a stunnel?

>
> No way. Debian has always avoided mindlessly dictating what runlevels
> must be used for. There's no reason to destroy this feature now. And
> there's no advantage to consuming an entire runlevel just to say
> "/etc/init.d/xdm stop" or "/etc/init.d/networking stop", which is
> all that you are proposing.

Still, better have init 2 than having to hack the boot command line to set
init=/bin/bash, having to remount in rw and editing whatever you XXXXed up,
before all the services go up and people start login into your server.

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

Where are you going, Starfish and Friends?
--Chad (Charlie's Angels)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

David Pashley

2005-06-08, 7:48 am

On Jun 08, 2005 at 08:07, Ian Campbell praised the llamas by saying:
> On Wed, 2005-06-08 at 07:54 +0200, Benjamin Mesing wrote:
>
> Debian already has a nice way to fix this -- if X doesn't start it tries
> a couple of times and then disables itself and offers to show you the
> log or drop you to a login prompt.
>
> I don't know if this functionality is from the X packages or from gdm
> etc. but it is a much better solution than the band aid offered by
> run-levels...
>
Plus you can always boot at runlevel 1 if you really don't want to
attempt starting X.

--
David Pashley
david@davidpashley.com
Nihil curo de ista tua stulta superstitione.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a