[SLE] how to run aptate
I am using suse 10.0 and installed apt4rpm using suse 10 dvd that was the cover disk in issue 55 of linuuser & developer magazine. aptate is installed and am having problems running it. aptate should produce a sources.list for suse 10. Any help in getting apt4rpm working in suse 10 would be appreciated. Below are some sites I used to try to get apt4rpm working, but no help on running aptate: http://ftp.gwdg.de/pub/linux/suse/apt/suse10-i386/RPMS.suser-rbos http://ftp.gwdg.de/pub/linux/suse/apt/suse10-i386/examples http://linux01.gwdg.de/apt4rpm/apt4suse.html http://apt4rpm.sourceforge.net TIA Joe Zien -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Wednesday 26 July 2006 23:48, Joe Zien wrote:
I am using suse 10.0 and installed apt4rpm using suse 10 dvd that was the cover disk in issue 55 of linuuser & developer magazine.
aptate is installed and am having problems running it. aptate should produce a sources.list for suse 10.
Any help in getting apt4rpm working in suse 10 would be appreciated.
Below are some sites I used to try to get apt4rpm working, but no help on running aptate:
http://ftp.gwdg.de/pub/linux/suse/apt/suse10-i386/RPMS.suser-rbos
http://ftp.gwdg.de/pub/linux/suse/apt/suse10-i386/examples
apt4rpm is the server, apt is the client. You are talking about *other* sites, so I assume you need the client, not the server. You would only need the server (= apt4rpm) if you would set up your *own* repository. Install the apt rpm, issue "apt update", followed by "apt upgrade" (as root). Take a good look of what packages apt is planning to upgrade, and if you don't like that, enter "n". Just hit <Enter> to continue. Add more repositories and/or sources in /etc/apt/sources.list. Cheers, Leen
Leendert Meyer wrote:
apt4rpm is the server, apt is the client. You are talking about *other* sites, so I assume you need the client, not the server. You would only need the server (= apt4rpm) if you would set up your *own* repository.
Install the apt rpm, issue "apt update", followed by "apt upgrade" (as root). Take a good look of what packages apt is planning to upgrade, and if you don't like that, enter "n". Just hit <Enter> to continue.
Add more repositories and/or sources in /etc/apt/sources.list.
Actually, aptate is quite of interest if one has the boxed DVD and wants to use that for installing more packages instead of downloading them. Then one can create a local repository and use that instead of the base component. If you're on a non-broadband connection, or if you have a volume-based connection, that's a Very Good Thing(tm) to do. That said, the apt-for-SUSE documentation could really be better, both for client and server usage. Especially repository selection leaves too many decisions to the user without giving information for guidance. And that the RPM options in apt.conf don't seem to be documented at all, is getting on my nerve, too. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Joachim Schrod wrote:
That said, the apt-for-SUSE documentation could really be better, both for client and server usage. Especially repository selection leaves too many decisions to the user without giving information for guidance. And that the RPM options in apt.conf don't seem to be documented at all, is getting on my nerve, too.
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) -- How to share the apt downloads between several systems and not download them for each system anew. -- How to hold dangerous upgrades (kernel, glibc), while still using apt upgrade for the rest. -- How to do daily auto-updates, or daily auto-checks for updates. And the two pages on the SUSE Wiki handle the issue in such a way that it's not clear where the best place for this additional information would be: http://susewiki.org/index.php?title=Installing_apt4suse where installation is handled and configuration might be appropriate, but where apt4suse is used and manual configuration of the apt system might not be appropriate; or http://susewiki.org/index.php?title=Installing_software_with_apt/synaptic where usage of apt is described and configuration might not be appropriate. Are there any opinions out there where to place such information in the SUSE Wiki? In one of these pages, or should one create a new page "Configuring apt"? I might transfer my own notes there, where I have described these tasks. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
On Saturday 05 August 2006 11:02, Joachim Schrod wrote:
Joachim Schrod wrote:
That said, the apt-for-SUSE documentation could really be better, both for client and server usage. Especially repository selection leaves too many decisions to the user without giving information for guidance. And that the RPM options in apt.conf don't seem to be documented at all, is getting on my nerve, too.
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 ;) (This is in the man page)
-- 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... try with exporting and importing /var/cache/apt, or /var/cache/apt/archives See YaST -> Network Services -> NFS Server and YaST -> Network Services -> NFS Client
-- How to hold dangerous upgrades (kernel, glibc), while still using apt upgrade for the rest.
?
-- 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. But it's better do do updates /manually/. Pay attention to what is about to be installed, and refuse if you're not happy. Cheers, Leen
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.
(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.
-- 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. 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. ;-) 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. Best, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
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
participants (3)
-
Joachim Schrod -
Joe Zien -
Leendert Meyer