One other problem I have with the proposal is that it assumes that questions
will be askedsequentially. But, this means that you won't be able to answer
a question, go on to the next, and then go back. (Except within a block of
questions that are all displayed at once of course.) The ability to go
Wichert Akkerman wrote:
> What's wrong with using the non-interactive frontends? Or a non-interactive
> option for normal frontends?
I guess I haven't thought the non-interactive frontends through. I was under
the impression they had to be pre-seeded with data about the questions. If
they can just
Previously Joey Hess wrote:
> This is a great proposal.
Thanks!
> But, it misses some of the stuff Ian Jackson proposed on an earlier thread
> on this subject. He was talking about allowing for completly unattended
> installs, as well as having a way to only see very important questions, etc.
Wh
Wichert Akkerman wrote:
>Configuration Management
This is a great proposal.
But, it misses some of the stuff Ian Jackson proposed on an earlier thread
on this subject. He was talking about allowing for completly unattended
installs, as well as having a way to only see
Previously Manoj Srivastava wrote:
> Actuall, maybe we should reconsider even that. The ast time I
> updated apt, 2200+ packages were updated. Having them in a flat
> folder is not likely to help browsing (heck, even a simple ls in
> /usr/doc takes perceptible time).
[pc135a;/usr/doc]-8>
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> [1 ]
Wichert> Previously Manoj Srivastava wrote:
>> Hmm. I wonder. Is there areason for a flat heirarchy? Could
>> deeper nesting have value? For example, there could be a "folder"
>> called MUA (or something), and all
Configuration Management
Rereading the discussions I realized it might be better to cleanly divide
this text into two sections: managing configuration data, and determining
configuration when installing packages. Hopefully this will result in a
better presentation of
Previously Raul Miller wrote:
> Or do we want to talk about creating a query system where the package
> pre-registers its queries with dpkg, and dpkg is allowed to obtain the
> answers to these questions before the package is unpacked? In some ways,
> this would be a cleaner system, but I'm not sur
Previously Manoj Srivastava wrote:
> Hmm. I wonder. Is there areason for a flat heirarchy? Could
> deeper nesting have value? For example, there could be a "folder"
> called MUA (or something), and all mail user agents go there, a
> higher level value (/top/mua/mailhosthostname) can be ove
On Jul 27, Jules Bean <[EMAIL PROTECTED]> wrote:
>> Marco d'Itri: probably GPG is not ready yet
>I understood the outcome of the last discussion here to be that it very
>nearly is. In particular, I'd like to note that GPG supports idea and rsa
It's not. RSA clearsigning has been fixed just
On Jul 27, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>> What about adding a --dont-configure flag to dpkg until we will have
>> all other things needed? That should be trivial.
>You can't force dpkg to tell scripts not to prompt.. Doing that is
I want to force it to not execute postinst scrip
Jules Bean writes:
> On Mon, 27 Jul 1998, Yann Dirson wrote:
>
> >
> > * DTM support (Definitive Type Manager, formerly Debian Type Manager)
> >
> > Federico di Gregorio: (La)TeX support is not yet ready.
>
> Is there a URL for this one?
Don't know. It is in slink since quite some t
Yann Dirson <[EMAIL PROTECTED]> writes:
> * Developer controlled automatic archive maintenance (eg removal of
> one's own packages automatically after signed email with list of
> packages to delete)
>
> James Troup: probably useless; needs a lot of work for minimal
> gain. People helpi
On 27 Jul 1998, Manoj Srivastava wrote:
> I can see value in deeper nesting of configuration
> variables. There is more structure this way; but that also entails
> more work creating the structure.
I think the possibility for deeper nesting is probably essential to the
future expandibili
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> [1 ]
Wichert> Previously Antti-Juhani Kaijanaho wrote:
>> No. Let the frontend define everything about presentation - including
>> order - as it sees fit. If a package _really_ needs a given order, it
>> should use a
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert>Installation-time Configuration
Wichert> The configuration space
Wichert> ===
Wichert> The configuration space is the realm in which all
Wichert> configuration information is stor
Previously Raul Miller wrote:
> What is the difference between a configmodule and the frontend? Which
> is to say, why doesn't the dpkg-vars util or link with the library
> contact the frontend directly?
The frontend is the part that the user sees: either a userinterface
(console,web,X11), or a n
Previously Antti-Juhani Kaijanaho wrote:
> No. Let the frontend define everything about presentation - including
> order - as it sees fit. If a package _really_ needs a given order, it
> should use a command that the language provides for that purpose. You
> refer to SGML and LaTeX in another po
Previously Raul Miller wrote:
> I thought you were trying to emulate what dpkg does with its conffiles?
I'm aiming for the same effect, not the same method.
> If the conffile exactly matches what was supplied by the package last
> time around, it gets replaced.
And if the tag says it was last se
Previously Raul Miller wrote:
> But md5sums are much smaller than most files, so more space efficient to
> store than a complete copy of the file.
But use a per-variable tag which indicates if a package or user has set it
is takes much less space then a md5sums. And it allows much finer-grained
ch
On Tue, Jul 28, 1998 at 01:18:20AM +0200, Wichert Akkerman wrote:
> The frontend has complete responsibility for the layout of the questions,
> with the exception that the ordering must not be changed.
No. Let the frontend define everything about presentation - including
order - as it sees fit.
Previously Raul Miller wrote:
> No. But that's unrelated to md5sums.
>
> For that kind of cleanup we need to have packages say "I'm using this
> value", and we need for package purge to take them off the list.
Like a proposed "dpkg-vars --purge --package xxx" ?
But I'm not talking about cleanups
Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Previously Raul Miller wrote:
> > Ok, but since most of these values will be pretty small, I think
> > direct comparison will make more sense than comparison of md5sums.
>
> You really want to remember all defaults for all versions of a package
> ever
Previously Raul Miller wrote:
> Ok, but since most of these values will be pretty small, I think
> direct comparison will make more sense than comparison of md5sums.
You really want to remember all defaults for all versions of a package
ever released?
Wichert.
pgpP9JbKkQtzt.pgp
Description: PG
Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> meta-data is actually quite simply. What I hand in mind mostly was a
> tag which says if the variable was set by a package or by a user. This
> way when a configmodule does DSET and the frontend sees from the metadata
> the variable was last set by the
Previously Raul Miller wrote:
> > We want to make a package which does not break older dpkg's ...
>
> Hmm.. I presume that this means that the lowest-common denominator
> front-end is always available, and it's up to the user to arrange
> for the presence of some other front end?
Correct. The sim
> We want to make a package which does not break older dpkg's ...
Hmm.. I presume that this means that the lowest-common denominator
front-end is always available, and it's up to the user to arrange
for the presence of some other front end?
> Each variable has associated with it one or more tags
27 matches
Mail list logo
