Re: how to run aptate

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: how to run aptate

Bugzilla from leen.meyer@home.nl
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
>
> http://linux01.gwdg.de/apt4rpm/apt4suse.html
>
> http://apt4rpm.sourceforge.net

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

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: how to run aptate

Joachim Schrod
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: [hidden email]
Roedermark, Germany

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: how to run aptate

Joachim Schrod
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: [hidden email]
Roedermark, Germany

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: how to run aptate

Bugzilla from leen.meyer@home.nl
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

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: how to run aptate

Joachim Schrod
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: [hidden email]
Roedermark, Germany

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: how to run aptate

Bugzilla from leen.meyer@home.nl
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

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]