-----BEGIN PGP SIGNED MESSAGE-----
On 2016-10-12 15:16, Marek Marczykowski-Górecki wrote:
> Currently most of Qubes OS repositories are about Qubes-specific code as
> almost all other components we pull from upstream distribution(s). This
> works well with our current repository naming scheme described here:
> As explained there, few of those are really 3rd-party software, but with
> some Qubes-specific modifications. For example Xen (vmm-xen), Linux
> kernel (linux-kernel), Libvirt (core-libvirt). In ideal world we'd use
> upstream versions directly...
> But recently there is more and more need to package additional software.
> This is because either:
> - package is Qubes-specific and unlikely to be included in upstream
> distribution (for example screenshooting tool made by Eva Star, or
> qubes-vpn by Manuel Amador)
> - upstream package is outdated and very unlikely to updated (this is
> mostly about dom0 packages, as we rarely update dom0 distribution);
> for example tboot
> - package needs some Qubes-specific modifications (already mentioned
> kernel, libvirt)
> - package is missing in upstream distribution; for example pvgrub2 (Grub2
> compiled with Xen support), scrypt
> Again, in ideal world, none of those would apply, but well...
> In the current scheme we'd use "linux-" prefix for such "generic"
> packages (like linux-kernel, linux-pvgrub2), and "qubes-app-" for
> Qubes-specifc extensions (all of them are maintained by Qubes team, so
> not exactly apply to this case). But I'm not sure what is the best
> approach here.
> 1. Stick with the current fuzzy rules: put the package in related
> component if applicable - so tboot would go into antievilmaid
> repository, otherwise create linux-* or qubes-app-* repository.
> 2. Always create linux-* repository.
> 3. Create one repository for all of them and use subdirectories (it's
> mostly about .spec files and sometimes patches...)
> 4. Create new organization on github and separate repositories there,
> possibly with different naming scheme - like "keep upstream name". If
> this one, we need a name for this organization... "qubesos-packages"?
> 5. Something else?
> Personally, I like the 4th option. Such approach is used by some projects
> already, for example https://github.com/salt-formulas for salt stack
> modules ("formulas").
> Any thoughts?
>  https://github.com/evadogstar/qvm-screenshot-tool
>  https://github.com/QubesOS/qubes-linux-pvgrub2
>  https://github.com/Rudd-O/qubes-vpn
Option 4 sounds fine to me.
Andrew David Wong (Axon)
Community Manager, Qubes OS
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.