Re: Smart Package Manager

On Sat, Dec 04, 2004 at 12:03:52PM -0200, Gustavo Niemeyer wrote:
> 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/.

Hmmm. Is the patch a bugfix that would be generally useful in the main RPM,
or is it more of a specialized fork kinda thing? If it would be generally
useful, let's try to get it into the main RPM package.

If not, then it's really a fork, and making a separate "rpmmodule-for-smart"
package which applies your patch and then installs that one rpmmodule.so in
the same place you're putting the pre-build binary is the right thing to do.


> 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.

Yeah, I totally understand. If you want, I can help maintain Fedora Core
packages..... (And try to get them into Fedora Extras.)


> > - 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.

I hadn't checked that out, but yeah, that looks like it might be okay. Where
*is* user-set configuration information stored?


> >   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.

Maybe there should be two timeouts -- first, try everything really quickly,
and if it isn't making progress in five seconds or so, skip it. Then, come
back to those if nothing else seems to be fast.


> > - 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.

It wasn't quite clear that the transaction had stopped, except for the way
it didn't take any time. It's also very confusing that this refers to a
problem with just one specific package, but of course the problem is with
all of the packages (or, looking at it from another point of view, from no
packages at all, but rather from the lack of a GPG key).

I have two suggestions here. First, if there's an error with a transaction
set, it'd be nice to show _all_ potential problems, not just the first one.
(I'm pretty sure that's what happens when sig checks fail in apt, for
example.) But at the same time, it wouldn't be helpful to scare users with a
list of 200 errors in a case like this -- instead, it should present a
summary. I guess this means a higher level of interpretation of the
underlying error messages reported by RPM.


> > - 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.

I figured there was some reason, but it's totally got to be stopped. :)

Maybe there shouldn't be a confirmation of 'upgrade' action, since that
doesn't really do anything to the system?


> > - 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.

This is a Fedora Core 3 thing, designed to take the guesswork out of the "is
kernel-smp or kernel supposed to be the default" problem. Basically, kernel
updates are now made default by the /sbin/new-kernel-pkg script (called in
the kernel's pre/post scripts), as controlled by the UPDATEDEFAULT setting
in /etc/sysconfig/kernel.

I think the problem is simply that the later-numbered kernel got installed
_before_ the earlier one. There should be something to ensure that doesn't
happen.


> > - 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).

Why doesn't changing configuration require privileges? Seems like an
un-privledged user could really confuse things!

In any case, what I was doing was uninstalling packages -- it acted like it
was working, but then applying changes did nothing.

I noticed that there's a "smart-root" consolehelper utility, but I haven't
checked out where it's used yet.


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

Whoops -- got distracted mid-paragraph. I mean: The FAQ seems to imply that
the "mirror" menu is for configuring automatic download of updated lists of
mirror URLs. But it's very unclear 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.

Okay, cool.


> > More later. Perhaps in a more organized way. :)
> Thanks a lot for all suggestions!

Oh, just you wait. :)

-- 
Matthew Miller           [email protected]        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>