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