Blog post about package management (aimed at fedora)

[Richard Hughes]

On Sun, 2007-08-12 at 17:42 +0200, Nicolas Mailhot wrote:
> Le vendredi 27 juillet 2007 à 11:28 +0100, Richard Hughes a écrit :
> 
> > "Crack" would be a valid comment but obviously, I would prefer more in
> > depth and reasoned criticism :-)
> 
> I agree with most of your stuff except:
> 
> - removing password requirement to install/update is very very stupid
> and dangerous (think script-kiddies, visiting kids that click
> everywhere, etc)

Well, my argument is that as soon as you give someone physical access to
the machine you've lost already. I'm betting that rm -rf ~/ would be a
bigger loss than installing an openoffice update in most people's cases.

> - auditing tools must be built-in from the start up. The desktop team
> likes to replace well-understood and easily verified scripts/CLI
> commands with callback-heavy black magic no one understands (sometimes
> several layers of black magic because you know it's so much easier to
> add a layer than fix the one underneath), without comprehensive doc or
> error reporting. This is somewhat acceptable for desktop toys but not
> for core stuff like system updates. 

I'm guessing the machines that have to be audited just won't use
PackageKit. It really is designed to just do the action after checking a
few policy knobs rather than a whole new system like red carpet.

> - while a lot of the updating pain is at the GUI level, and no one will
> mourn the current GUI update apps, you'll still need work at the yum
> level so 
>  * it does not barf at the slightest problem (on the CLI the sysadmin
> papers over yum ; in GUI mode that's somewhat less easy)

Define barf?

>  * updates are done in batches of small transactions instead of a huge
> brittle one (every time rawhide is frozen/unfrozen you get a huge 800+
> package update transaction which is almost sure to fail halfway)

Sure. I'm sure we could deal with this in a yum-plugin or something,
although rawhide unfreezing isn't my ideal use-case environment.

> - you'll need a CLI async client too for some user populations and it
> better be a real usable tool not a CamelCase-speaking monstruosity.

Yes, I already have an async command line tool.

> - if you go async client/server and allow an update client to remotely
> control updates of a pool of systems, you'll make a killing in the
> desktop enterprise space

I don't care about enterprise at the moment, I'm working on the typical
home-use system. I don't know enough about enterprise systems, nor don't
have any such desire to "fix" things there. Sure PackageKit might help
the enterprise use case but I'm not actively trying to address that
need.

Thanks,

Richard.