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.