Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=581220 --- Comment #13 from Kalev Lember <kalev@xxxxxxxxxxxx> 2010-07-02 21:30:27 EDT --- > Currently I have set the version to 2.6. So we are safe for the time being, > there is no problem with updating without introducing epoch. Are we allowed to > have _ in the version tag? Guidelines tell us to move the nonnumeric characters > to the release tag. I'm sure we are technically allowed to have _ in the version tag, but I think we don't want to do that. Keeping the version at 2.6 is fine. Another option would be to set version to 2.6.1 to take into account the _1, but it doesn't matter much either way. > They are not missing. The symbols of both are built into the same DSO. Aha, I guess that works for now. > > /usr/include/QtSolutions should be owned by qtsingleapplication-devel, > > otherwise removing the package will leave dangling empty directory behind. > > Nope. There is no need. qtlockedfile owns that directory. Yes, qtlockedfile-devel owns the directory, but that doesn't help us because qtsingleapplication-devel doesn't depend on qtlockedfile-devel. The directory needs to be owned by something in the dependency chain; if some other unrelated leaf package somewhere in the Fedora package collection owns the directory, it doesn't help us solve the problem here. There are a few options how to solve this: a) have both packages own the directory; b) have qtsingleapplication-devel depend on qtlockedfile-devel; c) let qt-devel own the directory. Option b is not a good one because it pulls in an unrelated package which we wouldn't normally need. Option a is what I think is the most correct approach here: https://fedoraproject.org/wiki/Packaging/Guidelines#Multiple_packages_own_files_in_a_common_directory_but_none_of_them_needs_to_require_the_others. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review