Hash: SHA512

On 2016-10-12 15:16, Marek Marczykowski-Górecki wrote:
> Hi,
> 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:
> http://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html
> 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[1] made by Eva Star, or
>    qubes-vpn[5] 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[2]
>  - package needs some Qubes-specific modifications (already mentioned
>    kernel, libvirt)
>  - package is missing in upstream distribution; for example pvgrub2 (Grub2
>    compiled with Xen support)[3], scrypt[4]
> 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?
> [1] https://github.com/evadogstar/qvm-screenshot-tool
> [2]
> https://github.com/QubesOS/qubes-issues/issues/2155#issuecomment-250929993
> [3] https://github.com/QubesOS/qubes-linux-pvgrub2
> [4]
> https://github.com/QubesOS/qubes-issues/issues/971#issuecomment-225843964
> [5] https://github.com/Rudd-O/qubes-vpn

Option 4 sounds fine to me.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS


You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to