Re: Thoughts about some new approx features ...
On Thu, Nov 16, 2006 at 10:40:42AM -0500, Eric Cooper wrote:
> On Sat, Nov 11, 2006 at 10:09:38AM +0100, Sven Luther wrote:
> > I just used approx to help me doing test installation with d-i.
> >
> > During this, there are 3 features, which i think may be useful :
> >
> > - ability to have approx take packages from more than one archive to put
> > them in the same repository.
> >
> > This would allow to easily override the standard debian d-i .udebs, and
> > make development of d-i much easier. Especially, since d-i doesn't support
> > more than one .udeb repository right now.
>
> Can you explain the desired semantics of this? Would this be like a
> search list (first one found), or union (most recent version among
> all), or something else?
Well, i was thinking of it acting the same way multiple sources work for apt.
I am not sure how apt does this, but apt has a configuration file which can
handle this. So i am not sure about the generic case.
For the use i personally envision, that is to be able have an override for d-i
.udeb packages, there would be various ways to handle this :
1) have some way to say that .../debian debian-installer/main ... comes from
a different repository than ../debian etch. or whatever, i am not sure of
the syntax, this way, the debian-installer .udebs can come from a (usually
small) local mirror.
2) have a more complete solution. That is you could provide more than one
apt source entry, and the highest version of the package would be used
(what i believe to be what apt itself does) in case of duplicates.
3) have a way to tell that one list will take precedence over the other,
independent of version of the packages. Typically, you would say : prefer my
local partial archive over the generic full one.
Well, this may be a bit confuse, but my main use will be simply to be able to
provide some packages in a local archive, and use the main archive for d-i
installation, plus the local archive for packages which override the full
archive.
> > - an option to automatically limit the approx archive to a given size, with
> > an least-used or oldest removal algorithm.
> >
> > This would allow to not care about approx.gc, and would allow to let
> > approx be running without having to think about it, and check that it will
> > not eat the disk.
> >
> > Maybe something like the auto-clean feature of apt would be nice too ? It
> > does keep only the latest version of all packages. Maybe something where
> > we keep only packages accessible by the diverse Packages files from each
> > repository ?
>
> That's exactly what gc_approx does -- removes everything not
> reachable from the Packages/Sources files. Couldn't you just make it
> run more frequently (default is cron.weekly, but you could make it
> daily or hourly ...)
Ah, nice. I didn't know gc_approx handled this in the cron table.
But the idea is also to put a upper limit of the disk space approx will use,
so approx will remove stuff if it reaches this.
So, let's say approx has a limit of 100MB, for example, it files packages.
Once it sees that the next package will break that limit (it knows about the
size of packages), it launches gc_approx (maybe while it is retrieving the
packages, not sure it this can be threaded, or gc_approx launched in another
process or whatever).
If this is not enough, then it erase non-duplicate packages, in a
last-recently-used or oldest replacement algorythm.
> > - Is there some way to control the syslog output, or to move the log into a
> > /var/log/approx rotated log thingy ? Using approx intesively sure does
> > file up the syslog quickly :)
>
> I can add a "quiet" mode that doesn't log anything unless there's some
> error condition (or maybe that should be the default, with a "verbose"
> mode instead?)
It is nice to see the packages being downloaded, but in repeated install, they
can pollute the normal syslog info, and you can miss stuff. So, the idea was
to use a different log file than syslog (/var/log/approx ?).
> Thanks for the suggestions.
No problem, thanks for a great tool :)
Friendly,
Sven Luther
Reply to: