On Tue, 2019-11-05 at 22:05 +0200, David Seaward wrote:
On Tue, 2019-11-05 at 11:55 +0100, Jonas Smedegaard wrote:
Quoting David Seaward (2019-11-04 20:55:31)
- Is the package ready for an everyday audience?
...
- Do we require updates to dependency packages?
...
- How do we handle releases to PureOS stable and PureOS next?
...
- How do we ensure packages are truly _maintained_ (not only
added)?
...
- What about security?
In the context of Liberty packages, I think answers to all of these boil down to the Librem One team taking responsibility. Functionally this means any problems should be directed to my inbox, and I'll figure out who can handle them.
One thing that might be useful is having "team maintainership" of the liberty apps. This solves single point of failure issues, at least in meat space. We may want to create a shared mailing list for the apps?
Before diving into details, I think a basic principle would be:
- Liberty packages will rely on the existing version of packages
already in PureOS stable. For example, we will rely on the existing versions of Python, GNOME or any Python libraries.
+1
- We may need to add new thid-party dependencies, e.g. Python
libraries, but will aim to minimise these. Such dependencies should be considered under our team control.
+1
- We will add new software built by our team. These packages should
be considered under our team control.
+1
Thus, it looks to me like there will be a Liberty "layer" on top of "PureOS stable". Is this sensible, and is there an existing mechanism to maintain a layer like this?
What is the "layer" here? Is it Liberty apps and their dependencies?
upstream > Debian > magical mechanism > PureOS stable
We can of course use the CI to build upstream > PureOS {stable,testing} simply by creating separate branches (one for debian and one for pureos) that hold the packaging and package for each distro respectively thereby building two packages for two separate distros simultaneously!
Once the path into Debian is established, we can use that if we prefer, but we can always use the pureos package to *quickly* update the package for security or other reasons.
Additional questions:
- Is there a single Debian release we will package against? I'd
prefer to avoid shifting dependencies.
I'd just chose unstable and let the chips fall where they may.
- I'm guessing the magical mechanism is in fact made up of multiple
components? If we have to define a pipeline of existing components, I'm happy to name it for future reference -- although I think another project uses Bifröst ;)
I think the best way is to package each of the components if necessary and then package each app individually.
I'm happy to help start out the packaging if someone points me to the build instructions. :-)
Cheers,
Jeremiah
Regards, David
P.S. I realise this doesn't exactly answer the original question, but I'm very biased >:>
PureOS-project mailing list PureOS-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project