Re: Smart Package Manager

> Here's my looked-at-it-for-half-an-hour comments. It's kind of a
> stream-of-consciousness narrative....
> 
> - looks pretty nice overall. I like the various tree views in the GUI;
>   perhaps one based on comps.xml groups could be added? I think that's
>   the most useful, as the RPM groups (in Fedora, at least) are a mess.
>   (The "High level interface" suggested in the IDEAS file....)

Yes, that's something interesting to look at. Should be pretty
easy to implement as well.

> - I wonder about the package name -- perhaps it should be
>   "smartpm-0.27-1.i386.rpm" instead of just 'smart'. I'm concerned about
>   confusion with the hard drive S.M.A.R.T. thing -- there's a "smartd" in
>   Fedora Core, for example.
>
> - the binary .so module in the source RPM is horribly, horribly ugly.
>   Please don't do that! Instead, perhaps a separate package which
>   actually contains the rpm source and the necessary patch?

Including the binary .so module is not beautiful, but it's the most
practical way to build a non-intrusive package so far. The correct
way to fix that is patching rpm itself, but forcing users to upgrade
rpm to some third-party package is not nice either. If you want the
used patches, they're available inside the tarball in contrib/patches/.

Also, please, notice that even though I've helped with suggestions
for Fedora, I'm not the binary package maintainer for any distribution
but Conectiva Linux.

> - I'm not so keen on not having a human-managable config file. This
> may make it a pain for us to push out config changes to our users. 

Interesting to hear that. One of the main reasons behind using
that format was exactly to easily push configuration changes to
users. Have you checked /usr/lib/smart/distro.py? That's a file
run everytime Smart starts, whose only intent is distribution-side
management of user configuration. It's certainly a *lot* easier
to maintain user configuration now than it was with apt.conf, or
any other kind of text file.

As a side note, the configuration file format may be easily
changed by replacing SysConfig with a class of similar
functionality, but with a different storage method.

> - I like the "Fix all problems" menu entry in the GUI. All programs
>   should have that. Or actually, there should just be a big button
>   on the side of the computer....

Hehehe :-)

> - tested on a freshly installed FC3 system, and attempted to update the
>   100+ packages that need it. It's taking a very long time to download
>   them all -- the first 60% went very quickly, but then it seemed to have
>   exhausted all of the fast mirrors and got everything else from slow
>   mirrors on the other side of the world. Now, it's stuck at 95%. If it
>   doesn't do anything soon, I'm going to cancel.

That's an interesting point Smart can do nothing about. If you have
mirrors registered all across the world, there's no way to tell if
they're good or not until you try at least once. Either you wait
until mirrors are properly tried out, or you select these mirrors
you prefer and register them for yourself using the Mirrors dialog.

> - Random thoughts while waiting -- it'd be nice if the "Operation
>   Progress" columns were sortable. And there ought to be a column for
>   package name (and possibly package file name) in addition to the URL.
>
> - the package download speed column seems to say "stalled" a lot, even
>   when the progress bar is moving quickly.

I'll check that.

> - hmm. well, pressing the cancel button has no effect. And ctrl-c in the
>   window where I ran the 'sudo smart --gui' command causes a traceback but
>   leaves the window up. Well, time for 'kill'.

Currently, Smart waits until unbreakable operations (connections, etc)
finish, and then returns. You're not the first to talk about this, so
I probably must find some other way to cancel downloads.

> - okay. Running again picks up where things left off, and picks good
>   mirrors. nice.

8-)

> - wait, what's this? "alsa-lib-devel-1.0.6-5.i386.rpm: public key not
>   available". Press okay, and nothing happens. Hmm. I guess it is aborting
>   this whole transaction? Not the clearest message....

This is an error message reported by RPM itself. Wasn't it obvious
to you that the operation was being cancelled, even the message
dialog being an error dialog? If not, perhaps I really should include
some kind of extra "Operation cancelled" message.

> - Okay, added keys with rpm --import, and hit apply changes. There we go!
>   Hmm, what does it mean to "clean" a package? Well, anyway, everything
>   seems to have gone okay.
>
> - Oh -- when appying updates, the "change summary" dialog comes up twice,
>   once before "apply marked changes now", and once after. That's odd.

That's because first you confirm changes being done by the upgrade
action, and then you confirm all changes being done in the system.
If you had some action marked before pressing on the upgrade button,
it will show up on the second dialog, but not on the first.

> - UPDATEDEFAULT is set to yes in /etc/sysconfig/kernel. Both the 678 and
>   681 updates were installed, and I ended up with the _older_ of those
>   as the default. Oops.

I'm not sure what you're talking about. Smart has done the right thing,
and installed the new kernel, correct? If so, there's some kind of extra
magic being done which is hidden from the package system.

> - if I run it not as root, the GUI lets me pretend do things, but they
>   don't actually _do_ anything -- just silently nothing happens.

Can you please let me know about actions where that happens? Smart
should allow you to do anything that doesn't require touching
privilleged sections (changing configuration, etc).

> - dialog boxes should be in the order "Cancel - Okay" instead of "Okay -
>   Cancel".

:-)

> - the mirror vs. channel thing is confusing. The FAQ seems to imply that
>   The "mirror" menu is for configuring files 

What is "configuring files"?

> - there's a --log-level command line option, but nothing actually seems
>   to get logged to syslog. Odd. Logging everything that happens is pretty
>   important to me.

This options changes the log level of the program itself, which
currently has nothing to do with syslog. Including support for
syslog is certainly feasible and desirable.

> - I will have to look at the 'modular interfaces' thing -- it'd be nice
>   to have one designed to run from cron and  generate pretty e-mail
>   messages to root.

Great idea!

> More later. Perhaps in a more organized way. :)

Thanks a lot for all suggestions!

-- 
Gustavo Niemeyer
http://niemeyer.net