[Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again

[Paul-Andre Panon]

On  Tue, 17 Oct 2017 5:36:50 ,  Robert Paschedag <paschedag.netlution at swr.de> wrote:
>
>Ok.
>
>Looks like I got it working now.
>
>After creating a very, very ugly script to add the missing headers to the Packages file, I discovered the deb822 module, already installed on the spacewalk-server (python-debian), which can easily parse a Packages file.
>
>With the information extracted with Steven Meiers "spacewalk-debian-sync" script (while syncing the Debian repo), modifying Packages was pretty easy.
>
>See a modified version of Steve Meiers script and the new script to add the missing "Multi-Arch" header here https://github.com/rpasche/spacewalk-debian-sync/tree/devel
>
>At least, this works pretty good on my test system, and after "apt-get upgrade", another "apt-get upgrade" shows "no packages to upgrade" ?
>
>Robert

I think going back to using a modified version of Steve Meier's script would be a step back that I would prefer to avoid. I would prefer to update the spacewalk-repo-sync command.

In addition to the rhn_deb.py file you indicated, there also appears to be a repo-specific plugin, deb_src.py, that appears to be pulling down the Packages file from the repo and determining what packages (and versions)  and corresponding URLs are available, https://github.com/spacewalkproject/spacewalk/blob/45553919f852c4dbc5fcfe1c24499b2f9e9f544b/backend/satellite_tools/repo_plugins/deb_src.py
One interesting thing is that that file has an empty get_updates() method which may be for Errata. If you were going to add a hook to incorporate Ubuntu errata (from https://lists.ubuntu.com/archives/ubuntu-security-announce/) and/or Debian errata, that may be where it would have to go but you would have to prepare a data/class structure similar to what the yum_src plugin uses (from yum.update_md import UpdateMetadata, UpdateNoticeException, UpdateNotice). You would want new classes to parse the external Errata sources (sub-classed for the distro, but you would need a new repo metadata field to determine the distro) and then would cross-correlate the results for what applies to that repo. Seems messy and an externally scheduled process may be somewhat cleaner.

Anyways, I think you're correct that rhn_deb is used to parse the deb packages. Instead of subclassing per repo, rhn_pkg fronts rhn_deb and the other package header parsers.
What populates the db tables (to add a multi-arch table row)? The sync() method in  spacewalk/backend/satellite_tools/reposync.py  probably invokes spacewalk/backend/satellite_tools/repo_plugins/__init__.py via the repo plugins (and load_checksum_from_header() calls the deb header parser), and the plugin __init__.py also has an upload_package() method which calls *push_package()* in  spacewalk/backend/server/rhnPackageUpload.py to populate the db with the parsed header values.

What I haven't yet figured out is 
a) what generates the Spacewalk Packages file from the DB tables or header data structures.

b) The Package class in importLib.py and packageImport.py in https://github.com/spacewalkproject/spacewalk/tree/45553919f852c4dbc5fcfe1c24499b2f9e9f544b/backend/server/importlib may be involved but I'm still figuring them out. I've seen one reference to rhn_pkg in packageImport.py, but it's in _import_signatures so they might not need to change.

So far, it looks like you would need to 
a) add the table with the DDL I gave earlier
b) change rhn_deb to include parsing the Multi-Arch header value
c) change push_package() in rhnPackageUpload.py to populate the new table
d) change get_info_for_package in spacewalk/backend/server/rhnPackage.py to download the multi-arch value from the new table.
e) change ? to add Multi-Arch to the Package file creation
f) it's non-profit

Cheers,

Paul-Andre Panon
Senior systems administrator