Bug#478904: cron script for apt needs improvement
On Mon, May 05, 2008 at 06:18:07PM +0200, Michael Vogt wrote:
> On Mon, May 05, 2008 at 01:08:22AM +0900, Osamu Aoki wrote:
> Thanks for your patch!
You are welcom. This was something I was doing for myself by manual CRON
job :-)
> > [ Osamu Aoki ]
> > * Updated cron script to support backups by hardlinks and
> > verbose levels. All features turned off by default.
>
> I like the verbose level addition, that is very helpfull. Could you
> please tell me a bit more about the hardlink backup mechanism? What is
> the use-case for this? It seems like it the MinAge feature in the cron
> script mostly takes care of this, or am I overlooking something here?
My focus is unstable while your focus is stable support. That may
explain why I do this.
Suppose very old large package was upgraded. Then we find new package
was broken. Size and age based aging will sure to loose them, I think.
It get worse, if we enable autoclean. Then we need to download them
again.
Hardlink back up as I use, especially used with CRON autoclean, only
keeps copy of up-to-date packages in archive without duplicated disk
space. The previous snapshot of archive is always available for several
days old state. (unchanged day not conted.)
...
> > I am not using Ubunts and many of recent these feature seems to be lead
> > by Ubunts stable support. I do not want to create problem for them.
>
> The unattended-upgrades support was developert for ubuntu. But there
> is no reason why it can not (or should not) used in debian.
You mean Debian stable (or possibly for testing). I agree too. It is
insane to do so for sid. (As you recommend).
> It works just fine there and the additional flexibility (blacklist
> support, conffile checking) compared to other solutions seem like a
> useful addition.
Yes.
> If there are multiple competing ones, we could just add a
> conf variable (like dir::bin::unattended-upgrades).
I am not going to work on this issue for short term. If I do, I will
use simpler shell version to function if Python one does not exist or
some variable specifies. After all, my focus is unstable.
> > On Sat, May 03, 2008 at 02:50:06PM -0300, Otavio Salvador wrote:
> > > Osamu Aoki <osamu@debian.org> writes:
> > > > On Fri, May 02, 2008 at 12:20:12PM -0300, Otavio Salvador wrote:
> > > >> Osamu Aoki <osamu@debian.org> writes:
...
> > I am doing it but its progress is too slow. I hope to see it finished by
> > tommorow morning :-) (Now: Mon May 5 01:03:23 JST 2008)
> >
> > $ bzr push --create-prefix sftp://osamu@bzr.debian.org/~/public_html/apt
> >
> > > We'd need to support backward compatibility but it doesn't need to be
> > > done quietly. We might output a warning to let user to know that he
> > > needs to change his/her configuration for the new variables and at
> > > Lenny+2 we can drop it.
> >
> > Anyway, these were undocumented feature in terms of normal document.
> >
> > Since I added onfigure-index this time, it is minimally documented and
> > tose old syntax are marked deprecated. So dropping them infuture is
> > doable.
>
> I agree that the old names fit better into the periodic namespace but
> I also think its not really worth to change them because its a small
> cosmetic thing and if we drop the old names in the future that will
> mean that a lot of our users (who customized them) will need to fix
> there configs.
As you see, both names are active now. I do not want to cause problem
if these changes have conflicts with Ubuntu case.
> > Since I made few extra verbosity control, I might have introduced bugs.
> > Quick look at shell -x result seems OK.
>
> Looking over the script I think the changes are ok. I would prefer to
> not have the huge fi/else cascade around line 334 but I understand
> that this is difficult to do in sh:
> ...
> debug_echo "download upgradable (not run)."
> fi
> else
> debug_echo "download updated metadata (error)."
> fi
> ...
But this is only logical to do this. indentation makes it quite clear
(it is soft tab stop 4).
What do you suggest otherwise in other language. Can you make
pseudo-python code to explain what you envision to be better?
By the way, I changed verbose level 1 to report only errors and level 2
to report progress. Then I moved other verbosety level up one in my
bzr. (I have not checked it yet. Time to sleep now.)
Osamu
Reply to: