[katello-devel] Spec failures - help?

[Lukas Zapletal]

> This order does not make sense to me. In order to run two versions of katello on a system (we're talking R&D here, not customer) the /etc/katello/katello.yml must not exist, and the local git version must be modified. This seems prone to inadvertently checking in a locally modified katello.ym into git.
> 
> Instead, if the git version was called katello.yml.example, then changes could be tracked there. With this name change, a locally modified version could also live along side it.
> 
> By changing the order to first check locally, you could actually install katello on your machine (which would add /etc), but also have local versions for testing (w/ local katello.yml).
> 
> If I'm the only one that sees a problem with QA scripts running out of /etc instead of local and the potential errors associated with this, I'll agree to disagree and live with it. :)
>

I don't see added value here. Yes, you need to watch out for the file in
the /etc in the current approach. That is a disadvantage.

On the other hand with your .example approach you always need to watch
out for changes in the git-tracked yml file (and keep coping your local
version with it). Every pull. That sounds annoying too.

By the way git allows you to override any files you want with your own
version. If you do this:

git update-index --assume-unchanged config/database.yml

the file will never be commited to the git anymore. But watch out - no
way to commit new version there. ;-)

So how about this, instead of loading /etc and then config/katello.yml,
lets add one additional step:

- load from /etc if exists
- load from config/katello-local.yml if exists
- load config/katello.yml otherwise

With this scenario we are able to:

1) Have decent default values in the git without any troubles.
2) Override anything you want with the local files.

This maybe does not solve your issue, reading it again. Ok. How about:

We can add a KATELLO_CONFIG value to the /etc/sysconfig/katello file.
Then you would be able to override it completely setting whatever you
want. That sounds reasonable.

Anything, but keeping our default git configuration untouched.

LZ

-- 
Later,

 Lukas Zapletal | E32E400A
 RHN Satellite Engineering
 Red Hat Czech s.r.o. Brno