On Tue, 17 Oct 2017 5:36:50 , Robert Paschedag <paschedag.netlut...@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 _______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list