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@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@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@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@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@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@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@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
_______________________________________________
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
