[Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again
Robert Paschedag
robert.paschedag at web.de
Fri Oct 13 21:00:01 UTC 2017
ok. Couldn't sit still. Tested the "Multi-Arch" header on stretch,
and....that seems to work
Using the Packages.gz file created by spacewalk, I can install "alex"
over and over again
root at stretch:/tmp# dpkg -l alex
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii alex 3.1.7-4 amd64 lexical analyser generator
for Ha
root at stretch:/tmp# apt-get install alex
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
alex
1 upgraded, 0 newly installed, 0 to remove and 358 not upgraded.
Need to get 0 B/605 kB of archives.
After this operation, 0 B of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
alex
Authentication warning overridden.
(Reading database ... 43532 files and directories currently installed.)
Preparing to unpack .../alex_3.1.7-4_amd64.deb ...
Unpacking alex (3.1.7-4) over (3.1.7-4) ...
Setting up alex (3.1.7-4) ...
Processing triggers for man-db (2.7.6.1-2) ...
Apt-Spacewalk: Updating package profile
root at stretch:/tmp# apt-get install alex
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
alex
1 upgraded, 0 newly installed, 0 to remove and 358 not upgraded.
Need to get 0 B/605 kB of archives.
After this operation, 0 B of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
alex
Authentication warning overridden.
(Reading database ... 43532 files and directories currently installed.)
Preparing to unpack .../alex_3.1.7-4_amd64.deb ...
Unpacking alex (3.1.7-4) over (3.1.7-4) ...
Setting up alex (3.1.7-4) ...
Processing triggers for man-db (2.7.6.1-2) ...
Apt-Spacewalk: Updating package profile
root at stretch:/tmp#
Now changing /var/lib/apt/lists/<my_stretch_packages_file> and add
"Multi-Arch: foreign"
as included in "control" of "alex" package, results in
root at stretch:/tmp# apt-get install alex
Reading package lists... Done
Building dependency tree
Reading state information... Done
alex is already the newest version (3.1.7-4).
0 upgraded, 0 newly installed, 0 to remove and 358 not upgraded.
root at stretch:/tmp#
If I remove the "Multi-Arch" header again, the old behaviour just returns.
So I think, including the "Multi-Arch" header for the package into the
database is a must have to support "stretch".
But maybe I just have a strange error and someone can give me a hint.
I still have to test that with *all* packages.
Regards,
Robert
On 10/13/17 21:17, Robert Paschedag wrote:
> Hi all,
>
> after fixing my problems with the errata import, I found another
> problem with Debian...especially with
>
> Debian "stretch" and SW 2.7. At least, I did not yet see a major (or
> even minor) error with Debian jessie on SW 2.7
>
>
> I can successfully deploy a Debian stretch system via SW 2.7, register
> it and install packages.
>
> The "installed" packages on the client is reported to SW. No problem
> so far.
>
>
> But, even if SW reports, that there are no newer packages in SW for
> the client, and I have done
>
> "apt-get upgrade" several times, the "client" does not recognize, that
> a particular package
>
> is already installed. I can install (for example "adduser") with
>
> "apt-get install adduser"
>
> over and over again. It does not tell.."that package is already
> installed with the newest version"
>
> The client also reports, that it installes the "same" version above
> "the already" installed version of this package.
>
>
> So, for example, my freshly installed debian system has 372 packages.
> After installation, "apt-get upgrade", it "always" upgrades about 260
> packages again and again and again.
>
>
> Also after applying
> https://github.com/spacewalkproject/spacewalk/wiki/DebianUbuntuSupportIn27
>
> on the client. It does not change. What is changed then, if that the
> "installed" packages is correctly "reflected" in the SW WebUI for that
> system.
>
> I *think*, that the problem is located on the client, especially in
> the "improvement of apt" in Debian 9 (see
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#apt-improvements
> and https://wiki.debian.org/DebianRepository/Format )
>
> ...
>
> If the following fields exist in the control file of a .deb file they
> also must exist in the record about the package in the Packages file
> and the value must match /exactly/ or a client might recognize a
> metadata mismatch and redownloads/reinstalls a package:
>
> * Depends et al
> * Installed-Size
> * Multi-Arch
>
> ...
>
> I know that the "Multi-Arch" header is not written to the packages
> list (see https://bugzilla.redhat.com/show_bug.cgi?id=1243387) and the
> workaround mentioned there (that I use for debian jessie) does not
> work here. The "Multi-Arch" header often has different values.
>
>
> I just want to know, if anybody can confirm this behavior.
>
>
> Next time I'm in the office, I'll try to modify the packages list to
> add the "Multi-Arch" headers (and their) values to the packages list
> and see, if this is really the problem.
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20171013/eab120af/attachment.htm>
More information about the Spacewalk-list
mailing list