Re: itp: static bins / resolving static debian issues
Justin Wells a écrit:
>
> OK, is there anyone who disagrees with this:
I rather agree. However some people were really not happy with wording
and a few glitches. As I would like to have this thread calm down as
soon as possible (it has become way too personnal), I make a few notes
here:
> -- sash becomes an "important" package so that it is installed
> by default. people who know that their systems will never
> fail can deselect it, but by default you get it
People objected that having a rescue solution (when the 'most-used'
rescue solution is using boot-disks, which is already provided) marked
as Important and thus installed by default is imposing this solution.
I have found that some packages I really do not need are installed by
default (may be tetex? I can't remember, and I really don't care).
The wording of Important is misleading: you never know if you will need
some exceptionnal rescue way of doing things. It should be installed
so that if you need it, it's there. Remember, size of installation is
no more really critical those days (people that need to install on small
hard drives should anyway browse through the Important packages).
So installing sash should not be a problem.
> -- we figure out what additional tools are required in order to
> get a root shell and repair a system, whatever sash does not
> already supply, and add that to some /sbin directory. Some
> examples: something to unpack archives (could be added to sash);
> as well as ensuring that you can get to sash as root: su,
> and sulogin will have to have static versions as well. In fact
> these are run so rarely I don't see why they can't be static
> by default--but if people yell, we can have separate static
> versions.
Well, the addendum was a bit unhappy. But I am all in favor of some
/sbin/static/* subdirectory, with the most important recovery tools. It
would be put in some package, let's call it 'static-sbins', with the
most important tools.
Moreover, a lot of adequate documentation should come with this: how to
recover using these tools, how to reset the path, how to install a
clone rootid, etc.
If sash has not already been installed, it should be recommended at
this point.
If the meta-packages are used, this should be recommended by a
'high availaibility' meta-package.
>
> -- root's shell be set to sash by default, if sash is installed
>
> That seems like an initial first step that would solve a lot of the
> problems I've talked about. It doesn't solve them all, but if we
> can agree on this we'll all be better off.
Well, this has been hot. I expectthat cloning root to sashroot is
rather more satisfying, however, it requires warnings about this.
Maybe add an alias to ~root/.profile to passwd, warning to change
sashroot's password when changing root's password.
Obviously, everyone is in favor of changing bash to ash for /bin/sh
> I'd still want to argue for more than this, but let's get this
> done first.
Please don't. Write some documentation instead. Before this flamewar
explodes, I was not aware of these possibilities, and I read a lot.
So an article on debian.org (is there some place for it on the web
site), sitting near the installation instructions, should be there.
BTW, the same thing ought to be done for security,
> The rest of what I want: less dependencies in the package manager;
> including that once the install scripts no longer use bashisms (already
> planned), the installer should no longer depend on bash, but rather
> on something less likely to be upgraded, like ash. And you all know
> I think the package manager shouldn't depend on dynamic libc.
These are wishlist bugs that can be filed against the adequate packages.
> However, it is one giant step forward to get the stuff above into
> the system if everyone agrees.
I think the most-needed thing is documentation. People can't guess
why bigger programs should be better if they were not told of what
could happen. I think you are in a good position to write a recovery
guide --- and in the right mood also. I don't have that much
experience: I had no software failure during the time I was a sysadmin.
Just bad wires.
NB: Everything here is my humble opinion. I am not a developer, English
is not my natural language, I have just been reading debian-devel since
ten months. I sincerely hope this message helps.
--
Jean-Christophe Dubacq
Reply to: