apt-proxy-users

[Apt-proxy-users] mirror features

[Micha <ear...@gm...>]

Hi,

i have another issue that might be my very own wish, but maybe others find =
it useful too.
Perhaps you can give a short feedback if this is the case.

It's the fact that my base station serves a dozen roaming customer laptops =
which i update when the owners are here for service or maintainance or what=
ever. I am aware that is not the standard situation ap2 is designed for, bu=
t it's still a situation where ap2 prooves most useful.
It's importasnt to note that my bandwith has limits, and there are good and=
 bad times to suck much stuff.=20

I try to keep my ap cache up to date completely, but to my knowledge this m=
eans i have to keep the packages installed on the main box. Where most of t=
hem naturally doesn't belong here.
There also are some packages i just like to have quickly available in case =
i'll decide (or need) to install, like kernel sources, but again i don't ne=
ed them installed yet.

There's the 'apt' option to only download packages, without actually instal=
l them and it's also a feature of aptitude (i don't know about the other GU=
Is). But it's still a circumstance to always maintain the 'order' list, and=
 do the aptitude cache cleaning.=20

I imagine there could be an optional configuration file with a list of pack=
ages that ap2 should update always at a specified frequency.=20
When there is a user request, then this 'additional stock' downlaodeds shou=
ld get a lower priority than that user requested  download.=20
For more diverse needs, this list could of course be autogenerated by a cus=
tom script, inserting effectivly all installed packages that are not on 'ho=
ld', or whatever selection you'd prefer.
This 'additional stock' could be downloaded eg. by night (with a cronjob) o=
r whenever the best time would be, in terms of bandwidth costs.

This would be a way to manage the ap cache content independent of user requ=
ests, to the extend of a real mirror.



  =B0
 /\/

Re: [Apt-proxy-users] mirror features

[Chris H. <ha...@de...>]

On Tuesday 01 Feb 2005 02:20, Micha wrote:
> i have another issue that might be my very own wish, but maybe others find
> it useful too. Perhaps you can give a short feedback if this is the case.
>
> It's the fact that my base station serves a dozen roaming customer laptops
> which i update when the owners are here for service or maintainance or
> whatever. I am aware that is not the standard situation ap2 is designed
> for, but it's still a situation where ap2 prooves most useful. It's
> importasnt to note that my bandwith has limits, and there are good and bad
> times to suck much stuff.
>
> I try to keep my ap cache up to date completely, but to my knowledge this
> means i have to keep the packages installed on the main box. Where most of
> them naturally doesn't belong here. There also are some packages i just
> like to have quickly available in case i'll decide (or need) to install,
> like kernel sources, but again i don't need them installed yet.
>
> There's the 'apt' option to only download packages, without actually
> install them and it's also a feature of aptitude (i don't know about the
> other GUIs). But it's still a circumstance to always maintain the 'order'
> list, and do the aptitude cache cleaning.
>
> I imagine there could be an optional configuration file with a list of
> packages that ap2 should update always at a specified frequency. When there
> is a user request, then this 'additional stock' downlaodeds should get a
> lower priority than that user requested  download. For more diverse needs,
> this list could of course be autogenerated by a custom script, inserting
> effectivly all installed packages that are not on 'hold', or whatever
> selection you'd prefer. This 'additional stock' could be downloaded eg. by
> night (with a cronjob) or whenever the best time would be, in terms of
> bandwidth costs.
>
> This would be a way to manage the ap cache content independent of user
> requests, to the extend of a real mirror.

I was thinking of a similar feature, that is not quite as flexible but would 
do the same thing but without needing to maintain a config file.

The idea is to use the Packages files and file databases to decide when to 
download new versions.  Any packages that had been downloaded by a client 
within a certain time (e.g. 2 months, settable by a parameter) could be 
automatically updated if a new version appeared in the Packages file for the 
backend.  If no client requested the package anymore after a certain period, 
ap would stop updating that package automatically.

It's not quite as flexible as your method, but would perhaps be easier from 
the user point of view, because there would be only 1 parameter to tweak 
instead of having to maintain a list of packages.

But whichever version you prefer, if you have time to implement it please go 
ahead and I'd gladly add it.

Chris

Re: [Apt-proxy-users] mirror features

[Luis M. <ga...@ot...>]

Chris Halls wrote:

>
>
>I was thinking of a similar feature, that is not quite as flexible but would 
>do the same thing but without needing to maintain a config file.
>
>The idea is to use the Packages files and file databases to decide when to 
>download new versions.  Any packages that had been downloaded by a client 
>within a certain time (e.g. 2 months, settable by a parameter) could be 
>automatically updated if a new version appeared in the Packages file for the 
>backend.  If no client requested the package anymore after a certain period, 
>ap would stop updating that package automatically.
>  
>
i think you shoul do that trought the conf file. Defining the time, if 
it is has a mirror or not.

>It's not quite as flexible as your method, but would perhaps be easier from 
>the user point of view, because there would be only 1 parameter to tweak 
>instead of having to maintain a list of packages.
>  
>
For this case there is no need to have the packages installed. justa 
make a txt list from dpkg -l > list.txt
and the apt-get install `cat list.txt` -d . I use that to have 
semi-automated esktop instalations and quite popular between the newbies.

>But whichever version you prefer, if you have time to implement it please go 
>ahead and I'd gladly add it.
>
>Chris
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Apt-proxy-users mailing list
>Apt...@li...
>https://lists.sourceforge.net/lists/listinfo/apt-proxy-users
>
>
>  
>

Re: [Apt-proxy-users] mirror features

[Chris H. <ha...@de...>]

On Wednesday 02 Feb 2005 21:46, Luis Matos wrote:
> Chris Halls wrote:
> >within a certain time (e.g. 2 months, settable by a parameter) could be
>
> i think you shoul do that trought the conf file. Defining the time, if
> it is has a mirror or not.

Sorry, that's what I meant by 'settable by a parameter'.

> >It's not quite as flexible as your method, but would perhaps be easier
> > from the user point of view, because there would be only 1 parameter to
> > tweak instead of having to maintain a list of packages.
>
> For this case there is no need to have the packages installed. justa
> make a txt list from dpkg -l > list.txt
> and the apt-get install `cat list.txt` -d . I use that to have
> semi-automated esktop instalations and quite popular between the newbies.

I was thinking that needs more effort than setting a config file parameter.  
What happens when package names change, e.g. a library package number 
increases, or a new kernel package is introduced.

Anyway, the ideal solution is probably to implement both methods :)  Anay 
volunteers?

Chris

Re: [Apt-proxy-users] mirror features

[Micha <ear...@gm...>]

Chris Halls <ha...@de...>:
> Anyway, the ideal solution is probably to implement both methods :)  Anay=
=20
> volunteers?

We'd need a kind of interface to attach to the daemon, and request a list o=
f packages. Like 'apt-proxy -u foo bar baz qux quux corge grault garply wal=
do fred plugh xyzzy thud'.
I can't do that, sorry, i was too busy with odd things in Brusseles than to=
 learn programming.

:)

  =B0
 /\/