Some further thoughts on the "language specific repositories" idea

[Jan Zelený]

On 24. 11. 2014 at 14:43:00, Nick Coghlan wrote:
> I started writing a long email regarding some of my concerns about the
> scalability of the "language specific repos" idea, and decided they'd be
> better to capture on the wiki instead:
> 
https://fedoraproject.org/wiki/User:Ncoghlan/User_level_package_management
> 
> 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 that
> (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 
quality/security/stability, ...

> The other main concern I have is around integrating with the build and
> 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
> services.

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 
there.

Thanks
Jan