[Spacewalk-list] Ubuntu 18.04 package management in Spacewalk 2.8

[Paul-Andre Panon]

On Thu, 6 Dec 2018 13:25:54 +0100, philippe bidault
<philippe.bidault at gmail.com> wrote:

>Hi Robert,
>
>Thanks for the script, really appreciated. Already implemented in my
>Spacewalk and for the moment, working like a charm.
>In fact it even solved an issue I had with the "netplan.io" package
always
>flagged as upgradable (I guess because of a missing header).
>
>Regarding the fake-upgradable Debian packages appearing on Spacewalk, I
>have 12 of them for the moment :
>
>? gcc-8-base-8-20180414-1ubuntu2.amd64-deb
>gcc-8-base-8.2.0-1ubuntu2~18.04.amd64-deb
>
>lib32gcc1-8-20180414-1ubuntu2:1.amd64-deb
>lib32gcc1-8.2.0-1ubuntu2~18.04:1.amd64-deb
>
>libatomic1-8-20180414-1ubuntu2.amd64-deb
>libatomic1-8.2.0-1ubuntu2~18.04.amd64-deb
>
>libcc1-0-8-20180414-1ubuntu2.amd64-deb
libcc1-0-8.2.0-1ubuntu2~18.04.amd64-deb
>
>libgcc1-8-20180414-1ubuntu2:1.amd64-deb
>libgcc1-8.2.0-1ubuntu2~18.04:1.amd64-deb
>
>libgomp1-8-20180414-1ubuntu2.amd64-deb
libgomp1-8.2.0-1ubuntu2~18.04.amd64-deb
>
>libitm1-8-20180414-1ubuntu2.amd64-deb
libitm1-8.2.0-1ubuntu2~18.04.amd64-deb
>
>liblsan0-8-20180414-1ubuntu2.amd64-deb
liblsan0-8.2.0-1ubuntu2~18.04.amd64-deb
>
>libmpx2-8-20180414-1ubuntu2.amd64-deb
libmpx2-8.2.0-1ubuntu2~18.04.amd64-deb
>
>libquadmath0-8-20180414-1ubuntu2.amd64-deb
>libquadmath0-8.2.0-1ubuntu2~18.04.amd64-deb
>
>libstdc++6-8-20180414-1ubuntu2.amd64-deb
>libstdc++6-8.2.0-1ubuntu2~18.04.amd64-deb
>
>libtsan0-8-20180414-1ubuntu2.amd64-deb
>libtsan0-8.2.0-1ubuntu2~18.04.amd64-deb
>
>Will try to dig, but indeed if the versioning motor is managed by Java
and
>not Python, will be hard to debug ...
>
>Regards,
>Philippe.

Hi Phillipe,

Back in January of last year, Marc Dalhaus created PR500, which fixed a
number of version parsing issues with Debian (but left the ones you
outlined above). The Git commits in
https://github.com/spacewalkproject/spacewalk/pull/500/commits appear to
show changes applied to backend/common/rhnLib.py,
backend/common/rhn_deb.py,  backend/server/rhnLib.py,
backend/satellite_tools/repo_plugins/deb_src.py, and
java/code/src/com/redhat/rhn/taskomatic/task/repomd/DebPackageWriter.java.
A quick glance appears to indicate the parsing is happening in the former.
If I remember correctly, after applying those changes we had to clear and
repopulate the repos so that all the DB package indexes would be
regenerated. Something to keep in mind to ensure that changes don't break
other stuff by fixing the cases you identified.

The two main parsing sections appear to be split between parseRPMFilename
in server/rhnLib.py

# 'n_n-n-v.v.v-r_r.r:e.ARCH.rpm' ---> [n,v,r,e,a]
def parseRPMFilename(pkgFilename):
    """
    IN: Package Name: xxx-yyy-ver.ver.ver-rel.rel_rel:e.ARCH.rpm (string)
    Understood rules:
       o Name can have nearly any char, but end in a - (well seperated
by).
         Any character; may include - as well.
       o Version cannot have a -, but ends in one.
       o Release should be an actual number, and can't have any -'s.
       o Release can include the Epoch, e.g.: 2:4 (4 is the epoch)
       o Epoch: Can include anything except a - and the : seperator???
         XXX: Is epoch info above correct?
    OUT: [n,e,v,r, arch].
    """
    if type(pkgFilename) != type(''):
        raise rhnFault(21, str(pkgFilename))  # Invalid arg.

    pkgFilename = os.path.basename(pkgFilename)

    # Check that this is a package NAME (with arch.rpm) and strip
    # that crap off.
    pkg = string.split(pkgFilename, '.')

    dist = string.lower(pkg[-1])

    # 'rpm' at end?
    if dist not in ['rpm', 'deb']:
        raise rhnFault(21, 'neither an rpm nor a deb package name: %s' %
pkgFilename)

    # Valid architecture next?
    if check_package_arch(pkg[-2]) is None:
        raise rhnFault(21, 'Incompatible architecture found: %s' %
pkg[-2])

    _arch = pkg[-2]

    # Nuke that arch.rpm.
    pkg = string.join(pkg[:-2], '.')

    if dist == "deb":
        ret = list(parseDEBName(pkg))
    else:
        ret = list(parseRPMName(pkg))

    if ret:
        ret.append(_arch)
    return ret


and parseDEPName in common/rhnLib.py


def parseDEPName(pkgName):
    """ IN:  Package string in, n-n-n-v.v.v-r.r_r, format.
        OUT: Four strings (in a tuple): name, epoch, version, release.
    """
    if pkgName.find('_') == -1:
        return None, None, None, None
    e = ''
    n, version = pkgName.split('_')
    if version.find(':') != -1:
        e, version = version.split(':')
    version_tmpArr = version.split('-')
    v = '-'.join(version_tmpArr[:-1])
    r = version_tmpArr[-1]
    return str(n), e, str(v), str(r)

That actually seems to be based on the Debian control fields definitions
here, https://www.debian.org/doc/debian-policy/ch-controlfields.html and a
big part of the issue appears to be that Ubuntu is breaking those rules
for the early package pre-releases.

If the filename is being parsed as
xxx-yyy-ver.ver.ver-rel.rel_rel:e.ARCH.rpm, how well does
libgcc1-8-20180414-1ubuntu2:1.amd64-deb fit? It doesn't, because
8-20180414 doesn't match ver.ver.ver.

The problem appears to be that we need
8-20180414-1ubuntu2  <  8.2.0-1ubuntu2~18.04
but 8-20180414-1ubuntu2 can't get the version parsed properly.

Cheers,

Paul-Andre Panon.