Build securedrop-admin-dom0-config package

[zenmonkeykstop]

WIP - this builds a dummy package securedrop-admin-dom0-config via the project's existing .spec file.

After investigation, it looks like there are two potential approaches to organizing the specfile to support multiple packages, the first being to have a null parent package that doesn't generate an rpm but sets common fields like License:

Name: securedrop
Version: 1.0.0
Release: 1
Summary: SecureDrop Qubes packages
License: AGPLv3

%description
I am a parent package description...

# subpackage number 1 - rpm name will be securedrop-workstation-dom0-config
%package workstation-dom0-config
Summary: SecureDrop Workstation configurator

%description workstation-dom0-config
I am the workstation package description...

# subpackage number 2 - rpm name will be securedrop-workstation-dom0-config
%package admin-dom0-config
Summary: SecureDrop Admin configurator

%description admin-dom0-config
I am the admin package description...


%install
# All packages' files are moved to buildroot here

%files
# parent package files - no files means no RPM

%files workstation-dom0-config
# workstation files here

%files admin-dom0-config
# admin files here

The other approach (followed in this PR) is to build the existing securedrop-workstation-dom0-config RPM as the parent package and just add additional ones:

Name: securedrop- workstation-dom0-config
Version: 1.0.0
Release: 1
Summary: SecureDrop Workstation configurator
License: AGPLv3

%description 
I am the workstation package description...

# subpackage - rpm name will be securedrop-workstation-dom0-config
%package -n securedrop-admin-dom0-config
Summary: SecureDrop Admin configurator

%description -n securedrop-admin-dom0-config
I am the admin package description...

%install
# All packages' files are moved to shared buildroot here

%files
# workstation files go  here

%files -n securedrop-admin-dom0-config
# admin files here

In the second approach, admin RPM files should be added to the Python MANIFEST.in so they get included in the source tarball used to populate rpm-build/BUILD. After that, how they're structured is up to the %install and %files <package> section.

Which we pick is really a matter of taste. If we did decide to split out the updater to its own RPM as a potential requirement for both the workstation and admin config packages, it might be worth trying the first approach. But for just one additional RPM, the second approach works fine.

[legoktm]

I think the first approach is probably cleaner and matches what we do in the Debian packages. Though it would be nice to get rid of the whole Python source tarball step (I remember Michael or Ro working on that a long time ago but don't remember why we got stuck)

On naming, I think just securedrop-admin-dom0 should be sufficient; it's certainly much more than config :) (Would be nice to rename securedrop-workstation-dom0-config to just securedrop-workstation at this point...) But probably keeping the -dom0 suffix here will be useful to distinguish from the securedrop-admin deb package that is going in the VMs.

[zenmonkeykstop]

I think removing the tarball would probably make option 1 a bit easier tbh. I'll look into it.

[conorsch]

Though it would be nice to get rid of the whole Python source tarball step

See #1565 for build logic that removes the need for "python sdist".

After investigation, it looks like there are two potential approaches to organizing the specfile to support multiple packages

Why would we not just create a separate spec file, one per package? If we're creating a new package securedrop-admin-dom0, then it should have its own spec file.

[legoktm]

Why would we not just create a separate spec file, one per package? If we're creating a new package securedrop-admin-dom0, then it should have its own spec file.

My understanding is that the spec file represents the source package, which in this case is all the files we maintain together in Git, which can then be split into separate binary RPM packages. Similar to how in the client we only have one debian/ directory that builds a bunch of different packages. (The server has two separate debian/ folders because of the OS difference, but the main securedrop/debian/ folder also works the same way in building multiple binary packages)

[conorsch]

Superseded by #1572, which includes @zenmonkeykstop's contributions here on the admin spec files.