On 12/16/2013 01:14 PM, Simo Sorce wrote:
On Mon, 2013-12-16 at 10:16 -0700, Rich Megginson wrote:
On 12/16/2013 10:12 AM, Petr Spacek wrote:
On 16.12.2013 17:55, Alexander Bokovoy wrote:
On Mon, 16 Dec 2013, Rich Megginson wrote:
Simo thinks that this is a reason why 'downgrade package' with
1.3.1.x
inevitably needs automated script which will purge two missing
plugins
from dse.ldif.
We have an upgrade/downgrade framework, it should be easy to
disable/remove these plugins.

Is that it?  Are there any other problems found attempting to
downgrade
1.3.2 to 1.3.1 in F20?
Packaging issue -- epoch will have to be increased and maintained
forever. It is weird but that's what it is.
Sure.  But that's a one time thing.  And, it's only for F20 - once
we go
to F21, we can remove the epoch.
No, and that's key here. Once Epoch is in place, it is forever.
Why?
Because that's how RPM is built. When Epoch value is absent it is
assumed to be equal to 0.
1.3.1.18-1 will be equal to 0:1.3.1.18-1 and less than 1.3.2.8-1,
however, 1:1.3.1.18-1 will be greater than 1.3.2.8-1 because the latter
is equal to 0:1.3.2.8-1.

Once epoch is there, it is to stay.
Anyway, is it a real problem? Personally, I consider it like
yet-another-version-number.

On my Fedora 19:
$ repoquery -qa | wc -l
46645
(packages in total)

$ repoquery -qa | grep -- '-[1-9][0-9]*:' | wc -l
6581
(packages with non-zero epoch)

No, not a real problem, but just one more hassle I'd rather not have to
deal with.
Yes it is a real problem, it is extremely confusing to people, because
it is not in the rpm file name.

It should be avoided if at all possible, and it is an unremovable tattoo
once you have it on.

So a decision to add an epoch number should never be taken lightly.

If you do not understand why, you should probably not set epochs.

Ok. We're going to try to fix the bugs in 1.3.2 ASAP, and do some testing in F20.

I have some 1.3.2.9 packages for F20 here: http://rmeggins.fedorapeople.org/rpms/

1.3.2.9 fixes the following issues:
- Ticket #47631 objectclass may, must lists skip rest of objectclass once first is found in sup
-- NOTE: this is the schema issue
- Ticket 47627 - Fix replication logging
- Ticket #47313 - Indexed search with filter containing '&' and "!" with attribute subtypes gives wrong result -- NOTE: this is one of the crashing issues (not the crash that appears to be syncrepl related)
- Ticket 47613 - Issues setting allowed mechanisms
- Ticket 47617 - allow configuring changelog trim interval
- Ticket 47601 - Plugin library path validation prevents intentional loading of out-of-tree modules - Ticket 47627 - changelog iteration should ignore cleaned rids when getting the minCSN
- Ticket #47623 fix memleak caused by 47347
- Ticket 47622 - Automember betxnpreoperation - transaction not aborted when group entry does not exist
- Ticket 47620 - 389-ds rejects nsds5ReplicaProtocolTimeout attribute


I'm trying to use copr to set up a repo: http://copr.fedoraproject.org/coprs/rmeggins/389-ds-base-testing/repo/fedora-20-x86_64/
but copr seems to be having some issues.

I also have a patch for 1:389-ds-base-1.3.1.16 for F20 ready to go - I tested upgrade from 1.3.2.7 on F20, works fine, disables whoami and syncrepl.


Simo.



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to