Re: RPM (Was Re: Deity project schedule problems)
On 24 Sep 1997, Manoj Srivastava wrote:
> Hi,
> >>"Enrique" == Enrique Zanardi <ezanardi@noah.dfis.ull.es> writes:
>
> Enrique> What about configuration at install time? We can mandate that
> Enrique> postinst scripts must not be interactive (it has been
> Enrique> suggested already), there's no modification to dpkg needed,
> Enrique> but do we want that?
>
> Before we can mandate that, we need to have a mechanism in
> place for package maintainers to still be able to configure their
> packages as the installer desires.
That's the point. We use interactive scripts to configure the packages
as soon as possible. RH uses non-interactive scripts, installs
every package in a default (perhaps unusable) state and the sysadmin
has to configure them after finishing the installation.
Their method allows unattended intallations/upgrades, but the services may
be down until the whole intallation/upgrade is finished and you reconfigure
them to suit your needs. Our method doesn't allow unattended installations/
upgrades, but the services are down only a few seconds. Right?
So there's no good in telling half the story ("See? RH scripts are not
interactive") if one doesn't think about the pros and cons.
> Despite what some people think, interactive maintainer scripts
> are not Pure Evil. They perform a useful and needed task: helping the
> installer configure the package to local requirements and
> inclinations, and to ensure that critical information is imparted to
> the installer. You can't junk the scripts unless you provide
> alternate methods to perform the same tasks (like a persistent
> variables cache, and a messaging system that can be used to bring
> things to the installers attention [and potentially log it]).
>
> I can mandate that pigs fly, but unless certain underpinning
> are provided (like wings), the mandate is meaningless.
I agree, of course.
> On the other hand, maybe it is time to revive talk about a
> configration variable databse/snapshot (the last time this
> degenerated into grandiose plans for a be all admintool, which will
> take time because of the scope).
I don't know if it's worth it. What is the current status of the admintool
proyect? Will we have a beta soon, that implement part of the requirements?
--
Enrique Zanardi ezanardi@ull.es
Dpto. Fisica Fundamental y Experimental Univ. de La Laguna
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: