On 24. 11. 2014 at 14:43:00, Nick Coghlan wrote:
I started writing a long email regarding some of my concerns about
scalability of the "language specific repos" idea, and decided they'd be
better to capture on the wiki instead:
In large part, it grows out of asking myself the question "What problem
are we actually trying to solve with language specific repos?", and it
seemed to mostly come down to having a way for users (including
developers) to install packages and manage dependencies *independently*
of the system package manager.
I can't speak for all the stakeholders here but one of the major goals is to
reduce the cost (or increase the efficiency if you will) of maintenance of these
packages at the expense of potentially lowering their quality. If we spend 50%
less time on packaging tons of different language modules, we can then use it
someplace else or re-invest it to get even more language modules to Fedora.
The latter case is also one of the intended advantages for end users. Also,
application developers often use upstream repo mechanisms instead of the
distribution ones. Having these "upstream" repos natively might increase the
ease of use for developers.
That then lead to some questions about the downsides of enabling
(especially around auditing) and whether it's really feasible to fully
support every single language specific packaging system at the platform
layer - at some point, we're going to just have to treat those systems
as opaque binary blobs, and leave the issue of handling security updates
up to the application provider.
You are absolutely correct. If we do this, we need to find a balance (or at
least an acceptable imbalance) between the maintenance costs and
The other main concern I have is around integrating with the build
review tooling - it seems to me like we may need an abstracted plugin
based hosting system like Pulp to make that a tractable problem, rather
than integrating directly with the ecosystem specific repository hosting
Probably yes. But again, we need to start with what do we actually want from
this ecosystem, then we can plan what tooling and processes do we need to get