On Saturday 05 August 2006 15:56, Joachim Schrod wrote:
Leendert Meyer wrote:
On Saturday 05 August 2006 11:02, Joachim Schrod wrote:
While I'm at it, other examples where the documentation is awfully inadequate: -- RPM key management (i.e., what to do when apt decides not to do an upgrade because public keys are missing)
apt --no-checksig upgrade apt --no-ch upgrade works too ;)
That's not a good solution, because it turns off signature checking overall which should not be done. One would have to use --no-checksig much too often.
apt --no-checksig install 'rpmkey*'
as part of the installation is the appropriate solution, IMNSHO. Then package signature checking works for all repositories that sign their packages.
Hmm, yes. What I presented was a hack, yours (below) is a solution. (I knew this, don't know why I didn't think of it...)
(This is in the man page)
While --no-checksig is in the man page, the real solution (how to import the typical keys) is not in the man page. The man page is also not the best place for it, as it is specific for SUSE, but an HOWTO page on the SUSE Wiki (or the apt4rpm pages at GWDG) would be.
I suppose importing rpm keys is not specific for the SUSE version of apt, but general for apt4rpm (the client part, i.e. apt).
-- How to share the apt downloads between several systems and not download them for each system anew.
you could share the apt cache directory I suppose...
Yes, and the lib directory, too. Best to place a respective conf file in /etc/apt/apt.conf.d/.
-- How to hold dangerous upgrades (kernel, glibc), while still using apt upgrade for the rest.
?
When one has both kernel and application upgrades outstanding, often one wants to do the application upgrades immediately and the kernel a bit later, as one has to reboot the computer afterwards. The same is for glibc, and also -- to a lesser extent in the case of workstations -- for the X11 server. Upgrade of such packages often must be scheduled and can not be done on a whim.
When one calls apt upgrade, these packages would be installed all together. Calling apt install for each of the application packages is a nuisance.
Therefore it is useful to hold back upgrades of such packages with RPM::Hold settings in apt.conf, and install them manually with "apt install" when the right time is there.
-- How to do daily auto-updates, or daily auto-checks for updates.
man cron, man crontab
Hmm, I suppose you did not have a look in /usr/share/doc/packages/apt? There are cron / init script examples there (apt-cron/)... ;P And gpg-check/ might also be interesting.
These directories are not installed in 10.0. Instead, 10.0 has autoupdate already prepared, that can be turned on in /etc/sysconfig/autoupdate.
But it's better do do updates /manually/. Pay attention to what is about to be installed, and refuse if you're not happy.
Yes, but one wants to have a job that emails a notice about the necessary upgrades. Ideally, one wants apticron from Debian, but this does not work on SUSE. So, new apt users should be shown the commands for such a update-check job. It might be obvious for you, but for many users it isn't. There are also variations -- e.g., does one want to download the archives during the check (i.e., does one use "apt -q -d -y upgrade"), or does one want to download them during installation (i.e., does one use "apt -s upgrade").
Overall, I think you misunderstood me.
Indeed, I did.
I did not ask these questions for me, as I know the answers quite well myself. After all, I administrate Debian systems since many years. ;-)
Well, if I had known (lack of docs, you knowing the solutions), I would have responded differently. :P
I listed issues that new apt users face and where the documentation is lacking -- my issue is not with the functionality (well, besides the missing apticron, and a working apt-show-versions would also be nice), but with the inadequate documentation.
I understand now. Cheers, Leen