[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