sounds nice.
there's another thing about apt-get which IMHO should be changed (if this
option already exists i'm sorry for being too lame for the docs): my
connection often suffers time-outs and i afterwards have to do a
--fix-missing. i think it would be nice if you could tell apt-get to try
again on timeouts.
regards
stefan
On Thu, Mar 16, 2000 at 02:18:25PM -0500, Tom Rothamel wrote:
> One of the minor annoyances in Debian is the prompting that goes on
> during package upgrades. It's not the fact that the prompting
> occurs... I like the fact that it doesn't silently redo the system
> configuration... but rather the fact that it occurs thoughout the
> upgrade process.
>
> Debconf helps matters. It allows for configuration questions to be
> asked the start of the installation process, which could then proceed
> automatically. At least, that's the theory.
>
> The problem I have is that dpkg keeps on prompting me as to the
> disposition of config files I have changed. Don't get me wrong, I like
> the fact that it asks me what to do... I just wish it would do it at
> the start, and proceed cleanly through the upgrade without further
> prompting.
>
> Since it would be unkind of me to subject the list to the above
> without proposing a solution, here's my answer to this:
>
> - When apt runs to upgrade packages, it will call a new program (which
> I plan to write) in the same way that it calls
> dpkg-preconfigure. TNP would scan the list of upgraded packages,
> looking for config files. (This scan could go rather fast, as it
> only looks at config files, rather than having to unpack the
> whole thing.) Where it finds changed config files (using the same
> rules as dpkg) it will add them to a list.
>
> The list will then be presented to the user, probably sorted by
> package. Each of the changed config files will be there, and the
> user will be able to select which ones he wishes to replace. (Other
> options, like show a diff, edit file, and background TNP will be
> given to allow the user to make an informed choice.) Once the user
> is through with picking which config files he wants to replace, the
> program will write the information to a well-known file and
> terminate.
>
> - The well known file will contain lines that look something like this:
>
> /etc/config/file0 package keep b20482b9ffb207ba5448cedee746c690
>
> The first entry is the config filename, the second is the name of
> the package it's associated with. The third is whether the config
> file is to be kept ("keep") or replaced ("replace"). I don't think
> it will be used directly by dpkg, but it would come in handy in the
> case of cluster upgrades, where a script might run over the file and
> replace all the md5sums on the files marked "keep". But in normal
> use it'll be ignored. The last field is the md5sum of the version of
> the file that will be used. I'll get back to that in a second.
>
> - Once the file is being appropriately created, dpkg will be modified
> to optionally take as an argument to an option the name of the well
> known file. It will read the information into a hash at the
> start. Then when a configfile prompt would be displayed, the
> filename and package are looked up to get a md5. If the md5 matches
> that of the old conffile, it proceeds the same as if one said 'N' to
> the prompt. If the md5 matches the new file, it's the same as
> answering 'Y' to the prompt. If the md5 is different from both, or
> the md5 can't be looked up, the normal prompt will be
> displayed. (This covers the case of a config file changing between
> TNP and dpkg runs.)
>
> This, along with debconf and a program like debecho (which doesn't
> exist, but if it did would allow logging of informational messages to
> a file) would allow for unattended installations and upgrades, after
> the initial Q&A session. I think that would be a real good thing to
> have, especially if we don't lose flexability when it happens.
>
> I'd like to know what people think about this... I'm considering
> starting coding on this during spring break next week, and it'll use a
> bit of infrastructure in common with ddiff. I'd also like to know if
> there's a preferred textui toolkit for use during installs/upgrades,
> or if I should just roll my own.
>
> I'm interested in hearing comments, suggestions, flames, summer job
> offers, package name ideas, etc... I would like to get going on this
> by next week, however.
>
> Oh, and for those who are wondering:
>
> I've decided to work on this rather than bettering ddiff integration
> because this is something that can work stand-alone to better the user
> experience, while ddiff will require new or different archives to
> achive maximum usefulness. (Ie, the diffs have to be stored
> somewhere.) I'll be returning to ddiff once I finish this, which
> should go rather quickly, and I'll probably do an ITP for ddiff before
> them. (I have the packaging essentially done, but I want to wait to
> hear back about some bug reports before a sponsored upload is done.)
>
> Lastly, is there a more appropriate list than debian-devel for
> announcing projects like this?
>
> --
> Tom Rothamel --------- http://onegeek.org/~tom/ ------- Using GNU/Linux
> Writing from home, just outside Northport, NY.
> The Moon is Waxing Gibbous (85% of Full).
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
