Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 166983 - app-portage/cfg-update-1.8.0-r6 stabilization request
Summary: app-portage/cfg-update-1.8.0-r6 stabilization request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High enhancement (vote)
Assignee: Harald van Dijk (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-15 09:26 UTC by Elias Probst
Modified: 2007-03-10 15:31 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elias Probst 2007-02-15 09:26:48 UTC
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:
Comment 1 Harald van Dijk (RETIRED) gentoo-dev 2007-02-15 14:20:09 UTC
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.
Comment 2 Harald van Dijk (RETIRED) gentoo-dev 2007-03-03 07:52:20 UTC
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.
Comment 3 Raúl Porcel (RETIRED) gentoo-dev 2007-03-03 12:07:50 UTC
x86 stable
Comment 4 Raúl Porcel (RETIRED) gentoo-dev 2007-03-03 12:08:06 UTC
Wrong button, sorry.
Comment 5 Simon Stelling (RETIRED) gentoo-dev 2007-03-03 14:36:31 UTC
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.
Comment 6 Harald van Dijk (RETIRED) gentoo-dev 2007-03-03 16:33:46 UTC
(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.
Comment 7 Simon Stelling (RETIRED) gentoo-dev 2007-03-03 18:17:13 UTC
(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.
Comment 8 Harald van Dijk (RETIRED) gentoo-dev 2007-03-03 19:41:24 UTC
(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?
Comment 9 Simon Stelling (RETIRED) gentoo-dev 2007-03-03 19:48:38 UTC
(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.

Comment 10 Simon Stelling (RETIRED) gentoo-dev 2007-03-03 19:59:21 UTC
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 ;)
Comment 11 nixnut (RETIRED) gentoo-dev 2007-03-10 15:31:03 UTC
Stable on ppc. Closing since we're last