389-ds-base

#556 updating package touches configuration files
Closed: wontfix Opened by rcritten.

Closed: wontfix
Reopen Issue

I had a custom certmap.conf as part of a pki-core install and after upgrading it was reverted to a standard certmap.conf.

389-ds-base-1.3.0.0-1.fc18.x86_64

This particular system had done some previous testing of these bits. When F-18 came out I wanted to sync it to reality so I did a: yum distro-sync

This downgraded to 389-ds-base-1.3.0-0.1.a1

Then I updated back to 1.3.0.0-1

setup-ds.pl -u is broken - it calls makeOtherConfigFiles with the skip flag == 1 - this is supposed to skip files that already exist - this is not working for certmap.conf - if certmap.conf exists, upgrade should not touch it

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=896256

Certmap.conf exists by default. So, it has no chance to be updated with the fix. But I think that's good. If we need to upgrade the certmap format, we have to do more work using some upgrade script...

Pushed to the following branches:

master 5285304756536917d1c6e8b708a68853f2a997e8
389-ds-base-1.3.0 57f4381395e2181e5610acc715e8c71592616ffd
389-ds-base-1.2.11 e63ad6840e4a9a62f3ffae27eaba1091653a1c50

Metadata Update from @rmeggins:
- Issue assigned to rmeggins
- Issue set to the milestone: 1.3.0.2

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/556

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
Metadata
None
None
None
Lowest
ack
IPA
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.