The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some ideas methods and techniques for ...



>>>>> "Chris" == Chris Fearnley <cjf@netaxs.com> writes:

    Chris> First, it should be possible to have a silent upgrade
    Chris> without needing the --force-silent.  Perhaps by copying the
    Chris> already configured config database from another server
    Chris> (after we develop such a best and have all packages use
    Chris> it).  Secondly, thinking about it, I'm not sure what dpkg
    Chris> --force-silent should do with the misbehaved package that
    Chris> asks for verbose input.  I mean if dpkg sent a [RETURN] to
    Chris> the maint. script will that /always/ give a default?  Could
    Chris> there be some package that requires one to hit [p/q] (and
    Chris> loops endlessly if the user doesn't choose p or q)?  How
    Chris> long does dpkg wait before it kills the maint.  script?
    Chris> And does dpkg leave the package in an unconfigured state
    Chris> (the user can run dpkg --configure manually later) or
    Chris> pretend that everything is honky-dory?

I'm about done replying to this thread.  What we have discussed is
interesting, but it is ultimately is serving no useful purpose.  The
original goal was to make upgrades as automatic as possible, and I
suggested that the postinst scripts of Debian packages could refrain
from asking questions at the user's request.  However, as I pointed
out in another message, Bruce has suggested that the configuration
information should be separated from the postinst script, much as you
have recommended, and stored for future use in a configuration
database that several people are trying to implement.  In his new
scheme, the user will be prompted for these data in a new Debian
script -- likely to be called "config", "configure", or something
similar -- and the postinst script will become truly non-interactive.
This meets our goal, and I am happy (or at least happier that I won't
have to sit through a dozen stupid questions after a routine upgrade).

The only other point that hasn't been fully addressed is what to do
when the user has modified a package's configuration file and there is
a new configuration file available.  Note that this will become less
common when and if the configuration database is implemented.  Right
now, dpkg asks the user what to do for each file.  However, I don't
see anything wrong with providing an option that tells dpkg to assume
that the answer to this question is always "no, don't replace the
current file."  The new version of the configuration file is still
available to be examined later, with a ".dpkg-dist" extension to
distinguish it from the real file.  Something, like this could be a
useful feature.

--
Brian


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com