Bugzilla Bug 166983

Request to mark cfg-update as stable on x86. I'm running cfg-update ~x86 since
more than a year without any problems so far.
Also I couldn't find any bugs that are still open.

Thank you!

Reproducible: Always

Steps to Reproduce:

That's probably a good idea. I'll wait until 1.8.0-r6 has been in portage for a
month or so, and if no problems present themselves, ask for that version to be
marked stable. Given that it has never been marked stable yet anyway, I think
this is better than marking an older version stable now.

Arch teams, would you please consider cfg-update-1.8.0-r6 for stabilisation?
There hasn't yet been a stable ebuild, so there's no hurry for getting rid of
an older version, but the package has been in the tree for almost two years,
and this specific version has been for a month, so I think it's about time. :)
Thanks.

x86 stable

Wrong button, sorry.

I'd like to see some minor things fixed before this goes stable on amd64:

* It installs the ChangeLog in /usr/lib/cfg-update, which seems rather odd.
* MD5 sum index should go to /var/lib instead of /usr/lib

Another thing that I don't like is that it is getting the MD5 sums from the raw
CONTENTS files, thus relying on portage internals. Granted, it's not very
likely to change in the near future, but still.

(In reply to comment #5)
> I'd like to see some minor things fixed before this goes stable on amd64:
> 
> * It installs the ChangeLog in /usr/lib/cfg-update, which seems rather odd.

That is odd. I never noticed it specifically before, but fixed now.

> * MD5 sum index should go to /var/lib instead of /usr/lib

Also fixed, thanks.

> Another thing that I don't like is that it is getting the MD5 sums from the raw
> CONTENTS files, thus relying on portage internals. Granted, it's not very
> likely to change in the near future, but still.

Unfortunately, I think reading /var/db/pkg directly is the least bad way for
cfg-update to work.

(In reply to comment #6)
> > Another thing that I don't like is that it is getting the MD5 sums from the raw
> > CONTENTS files, thus relying on portage internals. Granted, it's not very
> > likely to change in the near future, but still.
> 
> Unfortunately, I think reading /var/db/pkg directly is the least bad way for
> cfg-update to work.

Not really. dispatch-conf and conf-update provide basically the same
functionality with a different method: On startup, they calculate the md5sum of
the ._cfg????_ file. Either the user is going to use the default provided with
that ._cfg????_ file or he will use a customized version. The next time the
same file gets updated, they compare the md5sum they saved the last time with
the actual file. If they are the same that means the user used the default and
likely wants to the same again, so the update is merged automatically.

This is completely independent of any package manager and a lot faster then the
indexing cfg-update does.

(In reply to comment #7)
> (In reply to comment #6)
> > > Another thing that I don't like is that it is getting the MD5 sums from the raw
> > > CONTENTS files, thus relying on portage internals. Granted, it's not very
> > > likely to change in the near future, but still.
> > 
> > Unfortunately, I think reading /var/db/pkg directly is the least bad way for
> > cfg-update to work.
> 
> Not really. dispatch-conf and conf-update provide basically the same
> functionality with a different method: On startup, [...]

This means that they have no way of knowing whether existing configuration
files are modified, correct?

(In reply to comment #8)
> This means that they have no way of knowing whether existing configuration
> files are modified, correct?

Not before they were updated at least once. Yes, it's a drawback, but given
that out of the 860 files in /etc I have here I only ever updated 81, this
doesn't seem all that bad.

Anyway, except for the one design issue this seems to work fine, and in
practice it shouldn't really matter all that much, so this is stable on amd64.
I'll gladly discuss the details via mail though ;)

Stable on ppc. Closing since we're last