Smart Package Manager

[Gustavo Niemeyer]

Hello Rehan,

I'm copying the mailing list in that message, as I belive these
topics are of general interest.  I hope you don't mind.

> First of all Smart is a really excellent piece of software. I use it on
> Fedora Core 6 and Centos 4. It just works so much better. The dependency
> algorithms are really great but you know this already and things just
> run smoother and faster with the multiple connections.

I'm glad you like it!


> I work on an open sourced integration project ( www.trixboxtools.co.uk )
> and I am going to replace yum in my installer script with Smart. It
> should get the installation done in half the time.

I can't check it right now as I'm connection-less (flying), but
I'll have a look at it when I get a chance.


> To this end I have written a script (it's taken me ages to the the file
> parsing right :-(.) but I think it is virtually ready. The biggest
> problem I found with Smart was the difficulty in finding, installing and
> updating the mirror list. It's important for Fedora Core and Centos as

Have you checked out the channel of mirrors feature?  You can add a
channel that will automatically download and update the list of
mirrors.  If you have, can you please describe why it didn't work
for you so that I understand the issue?


> their bandwidth is donated and I did not want to make life difficult for
> them. I am attaching the script and it's supporting files. Could you
> please review the process. It seems to work really well in Fedora. It
(...)

I'm unable to check it out in detail right now, but if it's working
really well, it can't be that wrong. :-)


> I think this might help in the take up of smart on these platformsas I
> think everyone will be happier with the availability of the mirrors. BTW
> The fedora provided configuration points towards only one server. A
> problem with many repositories is that they do not publish a base url in
> easy to find places, as many of them use a mirror url the baseurl in the
> .conf files is out of date.

:-(


> I have some suggestions for future versions of smart that you might want
> to consider:

Cool.. let's see..

> 1)	Some times Smart gets stuck when it is being passed many mirrors
> on consecutive runs. I could not get the http::url//mirrors.txt to work
> properly (bash was doing screwy things with my file imports) so I have
> to import each mirror singly. This happens when it is looking for
> 'mirror descriptions'. Can you add a switch to not look for mirror
> descruiptions?

The "smart mirror" command will only consider the argument to be a
mirror description if given a single argument to --add and friends.
When given a single argument, the only way it handles it is as a
mirror description, so if you don't want to use mirror descriptions,
just ignore the fact that it has that feature.

> 2)	Typo - Smart mirror -show-penalities - penalities should be
> penalties?

I belive penality a different spelling of penalty.  In any case,
it's intentional, and not a typo. May be intentional *and* incorrect,
but certainly not a typo. :-)


> 3)	 Would it be more intuitive to set up mirror lists as a sub-task
> of Channel management? For example on the channel management dialog
> there might be a button that links to the mirrorlist dialog, how ever it
> fills in the baseurl for you.

Yes, integrating mirrors in the channel management UI would be cool.
Doing it properly may a be a bit tricky though.


> 4)	On the mirrorlist dialog an import function, e.g. a button that
> allows you to import mirros from a file or a place where you can paste
> the repos mirrorlist url. The mirrorlist url is a special case of a
> mirror getting the mirrorlist and importing mirrors in

Good idea.


> 5)	It would be nice if the base url can be a link to a dynamic
> mirrorlist (although I think that this would be difficult to make
> happen)

That's pretty much what mirror channels are for.


> 6)	On the main display it would be better for the user if the
> search was integrated and not a separate view (similar to the way yumex
> works). Perhaps a button or config option to only display the latest
> version in the database.
(...)

I'm not aware of how it works.  Can you please describe it, and
explain how it improves the user experience?


> When it comes time to install a package, Smart can explain why it has
> chosen an older version (to satisfy dependancies).

It does that when it shows the "Changes" window. Relations displayed
there affect only the ones that interact with packages in the
transactoin.


> If the main list has to show all versions available it
> might be better to display them similarly to the mirrorlist display
> using the 'twisty'. So the list just displays the base package name and
> if you click on the arrow it drops down a list of the files. I read a
> number of posts /reviews where this was an issue.

All the rants I've read about this ignore the fact that you may have
several *packages* installed *and* available (not just versions),
where each package has its own potentially different information.
I'm not saying that the expectation of users is wrong, after all
the UI is supposed to please users (that's where the U comes
from ;-), but I haven't managed to find a way to please users
in that area and still "respect" the technical reality.

Your idea is feasible, but it's not clear to me that it will
please users that complain about the current UI.  In fact, it'd
be just one more "Tree Style" view, where the package name is
the parent.

To really make everyone happy we'll probably have to design something
more interesting.


> 7)	 Also on the package list display, the groups view is pretty
> much useless. Not a fault of Smart but a limitation of the Redhat
> categories.

Please note that it's pretty much useless for those distributions
that don't have meaningful groups. It's not *intrisically* useless.
Many people, including myself, use that as their default views.

> More useful would be to display where that package is
> available (which repository).

You can do that right now. Just select View > Tree Style > Channels.


> 8)	A plugin system for lua scripts. This is just a 'nice to have'.
> It will make it easier to reuse other peoples lua scripts.

Smart is written in Python, which is a scripting language by itself.
In fact, Smart already has a plugin API, it just doesn't have
too many hooks yet, but it's something we can add.


> 9)	The twisty's on the mirrorlist display don't work intuitively.
> For example the initial display is everything expanded. If you close
> some of them and then delete one the list refreshes and everything is
> expanded again.

Can you please fill a bug about it in the tracker?


> 10)	A 'quiet' option which returns no output to the console (except
> perhaps 'error') for use in scripts.

That's a good one.


> 11)	On the cli/shell, the display of multiple downloads looks very
> messy. It might be an idea to clean this up. Attached is an example
> screen. The whole things can be updated once a second/half second giving
> a nice gui effect. Not sure how difficult this would be to code but it
> would give nice feedback to the user and properly show off smart's
> biggest advantage from a users perspective (multiple downloads!)
> 12)	On the subject of downloads, the downloads of package
> information 'seems' slow as it only does one repo at a time (of course,
> it is faster than yum). I am sure there is a reason for this but it
> would be nice to do more than one at a time just for speed.

These are nice ideas, but they'll take some energy to be written
properly.


> 13)	For people with slow connections or unstable lines it might be a
> good idea to be able to let them choose the max number of concurrent
> connections (say from 2 to 6) for downloads.

smart config --set max-active-downloads=4


> 14)	A way of locking package from only one repository. The priority
(...)

You can easily do that with priorities.  I can't see a reasonable
benefit in having yet another way to do these locks.


> Please let me know what you think of the script, the script is sort-of
> annotated so you can see what is going on but it is pretty simple. I
> am working on more repositories and should have these done soon. Any
> suggestions you have will be warmly received.

If I were to write it, I'd use a real language like Python since
there's quite a lot of text crunching, but if it's ready and it's
working well for you, way to go!

> Thanks again for an excellent piece of software,

Thanks for taking the time to prepare this (slightly long :-) message.

-- 
Gustavo Niemeyer
http://niemeyer.net