Latest thoughts on user level package management

[Nick Coghlan]

On 19 June 2015 at 17:24, Miroslav Suchý <msuchy at redhat.com> wrote:
> Dne 18.6.2015 v 17:42 Honza Horak napsal(a):
>> As for Aleph 4, the copr makes also sense to me, since at least part of the infrastructure would be shared. Mirku, what
>> would you say about building also non-rpm content in copr? Does it make sense to you at all?
>
> That really depends what really "redistributed component" is.
> Is it Docker image? That would be huge work. And we will have to adopt OSBS, which is not final yet. Lots of months of work.

No, in the context of the Aleph proposal, Docker, rpm-ostree, etc are
delivery formats not component formats.

> Is it ruby gem? Is it npm package?

Yes, this is about we might go about implementing the build side of
the https://fedoraproject.org/wiki/Env_and_Stacks/Projects/LanguageSpecificRepositories
idea

> Each of them would require more than month work. And it actually depends how good is
> the underlying tool. I spent a lot of work on mock to get better building of RPM and to fix bugs which caused us problems.
> It may happen that I will be forced to spent some times on gem, npm and other tools.

No near term change, just a conceptual question as to whether you'd
consider this in scope for COPR, and whether the general architecture
would support other package formats.

However, I now think the task is sufficiently different from the
current scope of COPR that I believe it would be better to have a
dedicated service that:

1. Managed a list of "approved for redistribution" packages, with a
record of the Fedora contributor that signed off on the package being
compliant with Fedora's licensing policy, appearing to be published in
good faith, and appearing to be benign (i.e. moved the package from
Aleph 5 to Aleph 4)
2. Registered approved components with https://release-monitoring.org/
in order to monitor them for updates
3. For Aleph 4 compatible ecosystems, when notified of an update for a
component, triggers a build for that component and uploads the result
to a Pulp repository running a suitable plugin (currently the only
ecosystem we have a plugin for is pulp-python)
4. Regardless of whether there's a Pulp plugin or not, provide a
straightforward way to progress a package forward to also generating
RPMs in COPR (i.e. making the transition from Aleph 4 to Aleph 3)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia