Fedora Project, give me 20 Million Euros or Free EDA software

[Matthew Woehlke]

Nicolas Mailhot wrote:
> Le Ven 6 février 2009 01:30, Matthew Woehlke a écrit :
>> We also have KHNS that makes it very easy to download and install 
>> themes and other such material *in a distro-agnostic manner*. This
>> benefits everyone, not just Fedora. +1 for not being self-centered.
> 
> And in return is application (or in this case DE)-centric.

Sure, but that just means that what we need is a tool that is both 
distro-agnostic *and* DE-agnostic.

> The usual drawbacks of this model are:
> 
> 1. not resilient WRT updates, unless you reinvent native package
> version tracking (nothing is never updated)

Yes, everyone should use RPM; other package managers should not exist.

> 2. does not permit controlled automated file pre-processing, unless
> you reinvent %build

And just what do you suppose needs to be processed to "install" a .ogg 
of a Haydn waltz?

> 3. does not permit notifying apps of deployment, unless you
> effectively hardcode a form of %post/%postun

This is silly. We're talking about content. Content should be scanned 
for periodically. Otherwise you're missing out on anything not managed 
by The One True Package Manager you're convinced is the answer to 
everything.

(This is also wrong; KHNS stuff is found just fine. You're claiming a 
problem that doesn't exist.)

> 5. not resilient WRT a change of mind of the host of the service
> (cddb), unless the metadata is put in the distributed payload, in
> which case you've finished reinvented a package container

Huh?

> 6. not resilient WRT interactions with the rest of the system (CPAN
> updates breaking other stuff)

And just how is installing "rickroll variant #72" going to break the 
system? Again, you're inventing problems that don't exist.

> 7. not promoting re-use or sharing, unless you reinvent native package
> dependencies tracking (and don't tell me no theme is ever updated or
> use material from other themes). Since people often don't bother,
> files are usually massively duplicated.

Shoving upstream into a .rpm isn't going to magically fix this. You'd 
probably have better luck getting upstream to distribute in a format 
that allows dependencies (which won't be RPM).

> 8. exclusive of other applications (example: OO.o dictionnaries
> distributed via OO.o extensions, TEX not sharing its fonts with other
> apps, etc)

Again, distro-agnosticism versus application-agnosticism. Fix *both*, 
don't just replace one with the other.

> 9. centralising model. Since you're locking distribution in an
> app-specific channel any third-party material needs to be copied
> inside your master repository to be deployed. rpm/yum and modern
> packaging systems allow setting up third-party repositories easily

Handwaving.

> 12. unless your organisation is very careful to track the upstream
> sources and licensing clauses of the stuff used inside its bundles,
> will quickly degenerate in a pile of files with unclear authorship and
> licensing (TEX). Contributory copyright infringement.

SHTDI. Why not fix this (where it's a problem, which it isn't in all 
cases) upstream and benefit everyone?

> So basically, the technical deployment tech is primitive, 

...and RPM has it's own flaws w.r.t. mutlimedia content. What's your 
point? At best, you're writing a whole bunch of code either way.

> its even more centralising and exclusive than packages,

One Repository to Rule Them All is centralizing and exclusive.

Show me a proposal that isn't Fedora-centric (and doesn't involve 
ridiculous infrastructure costs and single point of failure), and *then* 
I'll get excited.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Let's call it an accidental feature." -- Larry Wall