Re: release as a package or add to APTs file list?
Martin-Éric Racine <q-funk@pp.fishpool.fi> writes:
> On Wed, 19 May 2004, Goswin von Brederlow wrote:
>
>> > echo -e "\nUpgrading installed packages..."
>> > apt-get $UPGRADEOPTS
>>
>> This might fail if the cache is filled and /var nearly full.
>
> Not at all, since previous runs of this script would have cleaned the cache on
> their way out.
Lets say I just did a "apt-get install kde-i18n-*" during the
day. Thats 150MB or so. If they get updated the same night thats
300Mb. So the autoclean before this might be important to smaller var
partitions. It was just to emphasis the previous point.
>> > if [ -f /usr/bin/deborphan ]
>> > then
>> > echo -e "\nChecking for orphan files..."
>> > if [ `deborphan $ORPHANOPTS | wc -l | tr -d " "` = 0 ];
>> > then
>> > echo "No orphan file to be purged."
>> > else
>> > echo "Purging orphan files..."
>> > deborphan $ORPHANOPTS | xargs dpkg --purge
>> > fi
>> > fi
>>
>> Thats the same as calling
>>
>> debfoster -f -o RemoveCmd="apt-get --purge remove -y"
>>
>> right?
>
> No. Debfoster depends on keeper lists. For deborphan, this is optional.
Ok, but for the purpose of the script (cleaning up) both could
work. Its nice to have the choice.
>> > if [ -f /usr/bin/update-menus ]
>> > then
>> > echo -e "\nUpdating menus..."
>> > update-menus
>> > fi
>>
>> That should be done by the postrm scripts but what the hell.
>
> "menu" is such a sloppily written application that on m68k and hppa, I regularly
> get messages saying "cannot lock pid file, process already in use. aborting"
> because menu was already crawling its ass updating menus for one package and
> ends up missing updating them for the next package to install.
Someone wanted to write an apt-hook utility where one can register
jobs during apt-get runs and the apt-hook executes them when apt is
done.
The goal is to have just one script wait for apt to finish and have it
manage the rest. Also to run things like "update-menus", that might be
registered many times but only need to run once, just once.
Not sure what happened to it but you sound like update-menu would
greatly benefit from this.
>> That said some suggestions.
>>
>> You could check for debfoster or deborphan and use either one. I think
>> aptidute, once setup, has the same functionality to clean up the
>> system too. So you would have 3 options there.
>
> Debfoster depends upon deborphan. I will not add another useless dependency.
Package: debfoster
Depends: libc6 (>= 2.3.1-1)
Package: deborphan
Depends: libc6 (>= 2.3.2.ds1-4), dialog (>= 0.9b-20040316-1), bash (>= 2.05b-14)
Neigther one depends on the other.
> Likewise for aptitude. Meanwhile, APT is already there by default and deborphan
> is either a dependency or recommended for several packages.
>
> Note that I did NOT say that aptitude and debfoster are crap. I have only said
> that adding them as dependencies is not justified.
I think you misunderstood me. I was suggesting adding support for all
3 to your script and using "Depends: deborphan | debfoster |
aptitude". If the script can function with eigther of these you can
let the user choose his favourite.
(Also supporting more than one cleanup tool would speak against
merging the package into one of these tools and for keeping it
seperate)
You don't have to do it, its just a suggestion to add more features.
>> The script could be included in /usr/share/doc/deborphan/examples/ (or
>> other packages) and the manpages could be merged into the same
>> package.
>
> Including it in examples misses the point of having the script ready-to-use.
> It's not a "deborphan scripting how-to" it's a script on its own.
>
>> Deborphan/debfoster/aptitude could come with a cron job for
>> this included but have it disabled by default (Advantage being that
>> the script updates automatically and you only have to toggle one option).
>
> Proven to be somewhat dangerous, because several packages have severely broken
> assumptions if you run apt-get on a fully quiet and automatic mode.
If you don't like danger don't activatethe script. That's the same as
not installing your package. Same danger of breaking overnight.
Thats why I only do "apt-get -d upgrade; apt-get -d dist-upgrade" in a
cron job. That way I have all the debs downloaded locally in the
morning without the danger of breaking the system.
If I where to use your script I would add "-d" to the UPDATEOPS.
>> Another likely package to merge with would be apt-utils. Its a utility
>> for apt to improve it, like the preconfiguring of packages.
>
> Including it in apt-utils almost makes sense to me.
One more feature suggestion. Since your doing automatic updates the
danger of some man-in-the-middle attack is high. You should add the
configuration for apt and the needed keys to check the Release.gpg file
before updating. Then the script can be used to update stable +
security updates every night without adding a big security hole.
That is something that would also fit nicely into apt-utils or even
apt.
MfG
Goswin
PS: I know many people who have similar scripts so packaging one up
and making it the best script is a realy good idea.
Reply to: