Questions about mirrors and configuration

[Eric Brunson]

Hi all,

I've recently started trying smart having come from a couple of years
using yum, and I'm pretty pleased with it.  The speed and dependency
resolution are excellent and there are some features, like recommending
packages based on partial matches, that are really cool.  However,
coming from using rpm-apt, then moving to yum, please forgive me for
making comparisons between those two and smart, but if you're trying to
win converts, I believe that comparisons like that are going to be
inevitable.

I've been lurking on the list for a bit and reading the documentation
and I have a few question and also a few observations that you may or
may not consider worth discussion.

One topic, and the most important to me, is the handling of mirrors. 

rpm-md repositories usually maintain an online list of mirrors, but
smart doesn't seem to provide support for reading that list. 

I also feel that adding mirrors via the command line interface provided
could be less clumsy.  I wonder why the decision was made to relate
mirrors to a baseurl rather than the alias.  Since the alias is really
the unique identifier of the repository (the primary key, if you will)
it seems more intuitive to relate the mirrors to that, especially since
there's nothing to prevent creating multiple aliases with the same
baseurl, possibly to include different sets of mirror, say for speed vs.
completeness. 

This became most frustrating when I started to write a small script to
convert yum repo descriptions to commands to configure smart.  Yum
doesn't actually require a baseurl if given a mirrorlist, since the
first can be included in the list of mirrors, so in many cases the repo
file distributed for a repository will either have the baseurl commented
out (irritating if I'm trying to read the conf using a ConfigParser) or
completely missing.  Before trying to suggest any sort of fix for this,
I'd me remiss in not asking for the reasons behind the decision to
require a baseurl and relate mirrors to it rather than the alias.  Would
someone mind commenting on that?

Another point of contention for me is the decision to maintain
configuration data in a pickled file.  I definitely realize how much
that simplifies the code for saving and restoring the configuration
options, but it is very non-unixy and is in opposition to RedHat's
philosophy of being able to edit config files outside of any GUI tool. 
I realize that you support far more distributions than RH, but I
personally feel that the philosophy is a good one.  I also like being
able to open a config file in an editor, make changes as necessary, and
push that configuration out to many other machines.  I know the
arguement is that you can simply make the config changes via CLI on one
machine and push the updated pickled config out, but I think it's going
to be just one more hurdle to widespread adoption.

I'd be more than happy to contribute the code to save and restore the
configuration to a ConfigParser file if it's a question of resources,
but I'd also like to address the issues of the mirrors that I listed above.

I've tried very hard to present my opinions in as diplomatic a manner as
possible, so please don't take them as criticism's.  I really like smart
and would like to use it more, but these are a few of the issues that
are making me reluctant to switch over from more comfortable (to me)
utilitites, and I've seem comments on other forums that indicate others
find them an impediment to adoption, also.

Thanks for your time,
e.