Re: apt-listchanges, dpkg-preconfigure ordering in apt.conf
On Fri, Dec 01, 2000 at 03:30:28PM -0700, Jason Gunthorpe wrote:
> On Fri, 1 Dec 2000, Matt Zimmerman wrote:
>
> > As an optimization, I skip all processing of debs that are from a source
> > package that I've already read changelogs for. Reading control.tar.gz or the
> > status file is much faster than getting the changelog out of a large .deb.
> > Depending on where the changelog happens to be in the archive, you may have
> > to decompress and read the entire data.tar.gz.
>
> Hm, fair enough. However the new information is complete enought that you
> can init APT's cache (which is free since it is already done)
Good idea. I don't think I have any way to query the cache, though, except for
apt-cache. Then, I have to parse out the whole thing to get the info for the
version I'm interested in. I think I'll wait on the Perl bindings for that.
> > IMHO, the changelog should be part of control.tar.gz.
>
> Would be nice for alot of things.
>
> After you do this you should cookup an efficient caching changelog querier
> for the web site..
It would be nice if dinstall would put this information into a database. Then
the CGI would be trivial and very quick. dinstall doesn't seem to be packaged,
so I wouldn't know where to file this wishlist bug.
> > I'm already asking the user for their choices at install time via
> > debconf; why shouldn't I put them into the config file? They can always
> > be changed with dpkg-reconfigure, or the user can ignore it altogether
> > and override with entries in apt.conf. I would much prefer to dump
> > everything into the config file at once.
>
> hmm, debconf eh. I don't like mixing the 'how APT talks to you script'
> config with 'what the user wants' it makes upgrades unhappy.
>
> Maybe you need a pair of files, apt.conf.d/foo and etc/apt/listchanges -
> just use the new include directive in your conf.d fragment ?
>
> That sounds fair because then apt.conf remains the final config file that
> can override everything, you still have automatic upgrades of the cron.d
> fragment and debconf can fiddle with its own file.
>
> Might need condition include however..
Yes, the issue is that whether or not apt-listchanges hooks into apt depends on
whether the user decides that they want it at install time. I guess the best
solution is to create and maintain both config files in my maintainer scripts.
If the user wants it, the conf.d file will be created; otherwise, not.
/etc/apt/listchanges.conf will be created unconditionally with the preference
information.
--
- mdz
Reply to: