[DSE-Dev] Packaging policycoreutils for OpenSUSE

[Nicolas Iooss]

On Sat, May 12, 2018 at 2:53 PM, Matěj Cepl <mcepl at cepl.eu> wrote:
> Hi,
>
> I am changing jobs (Red Hat -> SUSE; R&D, but not a security
> related job), and although I will be switching my workstation to
> OpenSUSE, I would love to keep SELinux working. Which meant I had
> to dig into the current situation of SELinux and it is … not
> good. So, I started to repackage all SELinux packages 2.7 for
> OpenSUSE in my home build area
> https://build.opensuse.org/project/show/home:mcepl:SELinux
> . So,far I have packaged successfully packages for libselinux,
> libselinux-bindings, checkpolicy, libsemanage, libsepol, and
> python-semanage. Mostly I use original OpenSUSE packages for 2.6,
> but if needed I seek inspiration in Fedora packages.
>
> Unfortunately, I have trouble to package policycoreutils. First
> of all, I don’t understand what’s the difference between two
> upstream tarballs for it:
> https://github.com/SELinuxProject/selinux/archive/policycoreutils
> -2.7.tar.gz
> (linked from https://github.com/SELinuxProject/selinux/releases)
> and
> https://raw.githubusercontent.com/wiki/SELinuxProject/selinux/fil
> es/releases/20170804/policycoreutils-2.7.tar.gz
> (linked from
> https://github.com/SELinuxProject/selinux/wiki/Releases). What’s
> the point of confusing users with two different tarballs of the
> same name?
>
> Second, I don’t understand the behavior of the installation
> scripts. Looking at https://is.gd/MivaE1 , why in the world that
> installation scripts tons of stuff which is not part of
> policycoreutils? Could anybody help me to get through this
> obstacle, please?
>
> Thank you for any suggestions,
>
> Matěj

Hi,
After we have discussed about it on IRC (#selinux on freenode), I have
performed some tests on Github to better understand how its "Releases
page" work. The main issue here is that Github shows tags of the git
repository in the Releases page
(https://github.com/SELinuxProject/selinux/releases) and there is no
way to disabled this behavior. This has several consequences:

* Each tarball in https://github.com/SELinuxProject/selinux/releases
contains the full tree of the project (which is why "that installation
scripts tons of stuff which is not part of policycoreutils"), whereas
the tarballs in the wiki page are created by properly splitting the
subdirectories.
* It is not possible to delete what is currently in Github's release
page without deleting the tags.
* It is possible to "upgrade" a tag to a release by adding release
notes and files to them. For example
https://github.com/gentilkiwi/mimikatz/releases uses this (you can see
the differences between "Releases" and "Tags" pages of this project).
When there are releases like this, it is possible to remove them all
(for example using
https://github.com/stevemao/github-remove-all-releases), which
transforms the release page back to a list of tags (I have tested this
today on a test repository).

Moreover it seems that the Releases page can not be disabled (if it
can, I have not found how).

If my analysis of Github's release system is correct, would it make
sense to change the way the releases are currently tagged to only
create one tag (like "selinux-2.8-rc3") instead of creating one tag
per sub-project? Would this break some tools? (If distribution
packagers use tools to automatically detect when a new release is
available, would such a change break these tools?)

Cheers,
Nicolas
(IooNag on IRC)