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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
