As a recent convert to createrepo_c I am all for this. When I was new
to Koji, I was a bit overwhelmed in getting it all working. The
documentation was so much more sparse then. I saw mention of
createrepo_c at the time but I was more concerned in getting things to
work at all. By the time I had things going relatively smoothly, I'd
simply forgotten about this, until about a month ago when I stumbled
upon it again while investigating some other issue. Imagine my
surprise when I found out how much faster it was.
I then worried about keeping the change. What was the downside of
using createrepo_c? There had to be a reason this wasn't the default
after all. I get not wanting to break backwards compatibility, but in
complex systems like Koji you really ought deliver the best experience
by default. Communication of such changes is the key. Make breaking
changes obvious in the release notes right up top and just do it!
On Wed, 2018-01-03 at 07:10 -0500, Neal Gompa wrote:
> On Wed, Jan 3, 2018 at 7:09 AM, Tomáš Kopeček <tkopecek(a)redhat.com>
> wrote:
> > Hi,
> > is there anyone still using old createrepo and mergerepo, or does
> > it make
> > sense to deprecate it and e.g. in 1.18 remove support for
> > createrepo and
> > bundled mergerepo and make current option use_createrepo_c default
> > behaviour?
> >
> > I haven't seen any problem with current versions of *_c which are
> > 1) faster
> > 2) we don't need to bundle it and fix bugs there.
> >
> >
https://pagure.io/koji/issue/716
>
> I'm using createrepo_c exclusively. I'd rather the old stuff get
> purged.
>
>
> --
> 真実はいつも一つ!/ Always, there's only one truth!
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.o
> rg