Questions about mirrors and configuration

[Gustavo Niemeyer]

Hello Eric,

Apologies for not answering your message before.  I've got two weeks
to rest a bit, and a working trip immediately after. I'm still trying
to catchup on the pending mails and activities (that catchup procedure
is happening more often than I'd like, but such is life).

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

No doubts.


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

Do you have information about that additional file, like who is
providing it, and what's the format?  The format described at
http://linux.duke.edu/projects/metadata/ doesn't seem to include
mirror information.


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

I can mention a few different reasons:

1) The current system allows specifying partial mirrors. For instance,
   you may setup Smart to download packages from one place, but
   repository details always from the same central server, ensuring
   that you have the most up to date information. I used that myself
   a few times.

2) It's also common to have a whole set of channels mirrored at the
   same place, because they're part of the same distribution. It's a
   lot easier to setup a single mirror entry explaining to Smart what
   the mirror is really mirroring, rather than saying for each entry
   that it's on the same server.

3) Most importantly, that's the most general way to build mirror
   support. Smart understands many different channel formats, and
   each of them have different information needs. Sometimes you need
   two urls for different metadata, and so on.


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

I understand your frustration. Fortunately, this is just a data
migration procedure, which shouldn't last long. If you haven't
managed to create the migration system you need, let me know and
I'll help you.

> 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 agree on all points.

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

This is going to be very welcome, and indeed it's on the (endless)
TODO list. The only code you should have to touch lives in the
sysconfig.py file. Replace that class with something else and you've
got your text-based config format.

Let me know if you want to do it, and if you need additional
information.

> 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 a lot for taking the time to detail so carefully those issues.

-- 
Gustavo Niemeyer
http://niemeyer.net