Pondering the Emacs add-on packaging situation

[Przemek Klosowski]

On 06/24/2015 07:31 AM, Jonathan Underwood wrote:
> On 24 June 2015 at 08:01, Jan Synacek <jsynacek at redhat.com> wrote:
>> Managing Emacs packages by the distribution makes, IMHO, no sense at
>> all. Users can easily manage the packages themselves via Emacs'
>> package.el user interface.
> Well, that's the way I'm leaning too. But then, I could make similar
> arguments for python, perl etc.

Exactly, and not in a good way! It seems to me that we worked hard to 
create a packaging system that keeps the system updated and secure... 
and now retrench away from the idea. The revisionists seem to argue two 
things:

  -  it's too hard to keep large subsystems consistent and free from ABI 
clashes, so we need project-oriented contained setups

  - it's OK to give up on the security advantages of unified 
system-level updates because subsystems have limited scope.

As you say, this argument is made about Emacs, Python, Perl, Node.js, 
and containters in general.  I am very troubled by this trend: at worst 
it leads to stagnant, vulnerable backwater subsystems ( "over 30% of 
official images in Docker Hub contain high priority security 
vulnerabilities", 
http://www.infoq.com/news/2015/05/Docker-Image-Vulnerabilities ); at 
best, it means that the end users have to orchestrate several 
independent update processes. Simply not keeping stuff updated is not an 
option---usually, all the imporant data is in the project, and even a 
contained compromise that didn't  subvert the core OS means game over 
("All my data was stolen/erased through a browser exploit, but at least 
the kernel was not compromised".. NOT).

This fragmentation leads to weird effects, such as the one I just 
discovered with Node.js: the standard 'node' installation fails to use 
the system-wide packages installed by 'npm' and Fedora RPMs, because 
they use different paths; the node subpackage RPMs are basically 
unusable as delivered. This is because node upstream believes in  'local 
packages'.

We should not give up on the principle of installing all software 
globally, within the RPM framework. I hope there's a way to accommodate 
subsystem-specific  packages, but it probably requires specific things 
in each environment, rather than a universal solution that works for 
every one of them.

Now, there are a couple of tradeoffs and issues to consider:

- big collections,  or lots of little packages (l think TeXlive is 
overdoing it with 5323 packages)

- can system/global packages  be overriden by a local copy (especially 
if upstream prefers local)
     - in particular, are global packages immediately usable, or do they 
have to be 'linked' locally first

- does Fedora just fix the issues for itself, or do we try to push it 
upstream

I think we should discuss these issues and had a consistent policy to 
draw on in similar discussions in the future.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150624/35a1ed23/attachment.html>