| Summary: | Files and libs duplicated in mate-dictionary and mate-utils | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | mate-utils | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | dan.mashal, fedora, rdieter, stefano |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | mate-utils-1.6.0-8.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-09-15 00:53:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Since 1.6.0-2 mate-utils is splited in some single packages for each application, and a meta package which includes all applications. We wanted to give the user the possibility to install only needed single packages or install all with the mate-utils meta package. This is also very useful for comps and livecd images. RPM is able to handle this and we have no package conflicts. Not so fast, please. This is really odd packaging. mate-utils is not a meta-package. A meta-package doesn't contain any files, but just dependencies on other packages. The correct and cleaner way to package this would be for mate-utils to require mate-dictionary (and the other subpackages). And in case there are shared files the individual subpackages need, these are to be split off into subpackages as well. [...] I've posted to packaging list about this. So far, it has always been a packaging mistake to duplicate files (and their Provides as a consequence) into multiple subpackages. .....i'm only the co-maintainer....not my idea. Does that mean you agree that it's a packaging bug? Then we can spare ourselves the hassle. ;) (Just imagine one of the existing sub-packages would be replaced with something from a separate src.rpm. What would happen to the duplicate files in the mate-utils package?) (In reply to Michael Schwendt from comment #4) > Does that mean you agree that it's a packaging bug? > > Then we can spare ourselves the hassle. ;) > This means i agree with you that a split of mate-utils can be done in a better way without duplication of binaries and libaries. ;) Saying this without a practical test. But it makes no sense that i repair the split again as you can see in changelog. Better a job of the maintainer. > > (Just imagine one of the existing sub-packages would be replaced with > something from a separate src.rpm. What would happen to the duplicate files > in the mate-utils package?) There is no seperate src.rpm for mate-dictionary,ie. All subpackages has only one mate-utils.src.rpm. If only mate-dictionary is installed than installing mate-utils will handle by yum/rpm without creating a package conflict from the dublicate files. I was very surprised for myself about this. But again i agree with you to split the package without file duplication. I can help fix this, looks like there are a couple issues going on here, but it all boils down to the same duplication issue. 1. It would appear that all (most?) of the mate-dictionary subpkg content is duplicated in the main package. 2. essentially identical -devel subpkgs (varying only in name). I'd propose to remove all dict-related content from the main package, and to drop (Obsoletes) the mate-dictionary-devel subpkg in favor of keeping mate-utils-devel If there is no comment or objection, I'll get to work on this soonish. Re: comment 5 The bottom of comment 4 has been misunderstood: Yes, "there is no seperate src.rpm for mate-dictionary" _currently_. I wrote "_imagine_ (!) one of the existing sub-packages would be replaced with something from a separate src.rpm". What would happen in that case? -> The build from the separate src.rpm could obsolete (=replace) the mate-dictionary package, but what could it do about the duplicated files inside the mate-utils package? Nothing. The mate-utils package would need to drop the duplicated files and gain a dependency on the mate-dictionary replacement package. That's *exactly* what ought to be the case already: mate-utils Requires mate-dictionary ... plus the other sub-packages, too. OK, please review: http://pkgs.fedoraproject.org/cgit/mate-utils.git/commit/?id=687d681624c3159341e27f15eff5d4e477b9c100 Wasn't entirely sure what to do with an essentially empty main package, figured we could use that as a metapackage for installing everything (and upgrade purposes). Thanks Rex, looks good to me. Hope that Dan also read this topic and your spec file, and learnt to split a package without doing it himself. We can also remove --add-category="X-Mate" from desktop-file-install, no need for this since MATE is registrated for OnlyShowIn. Also using --with-gnome in %find_lang seems to be not necessary, imo. Will fix this in next build. > Wasn't entirely sure what to do with an essentially empty main package, > figured we could use that as a metapackage for installing everything That's what comment 1 explained. > please review: It fixes another mistake that has been missed. The previous build of mate-utils did not contain the /usr/share/mate-utils directory, so it was incomplete: $ rpmls -p mate-utils-1.6.0-7.fc18.x86_64.rpm|grep share/mate-utils $ If the -common package is arch-specific, I would add %{?_isa} anywhere it's required and also to the several subpackage deps in the meta package. > %package devel > Summary: Development files for mate-utils Mixed feelings here. Currently, this -devel package is specific to mate-dictionary and its shared library API. I cannot tell whether there will be devel files for the other utils ever. It would be okay to build a mate-dictionary-devel package instead. That would be a more clear name than deriving its name from the mate-utils meta package. Thanks. Indeed -common was intended to be noarch, I'll fix that. Re: the -devel thing, I too had mixed feelings (nothing currently BR's either version, so folks can change their minds later without too much fuss). mate-utils-1.6.0-8.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mate-utils-1.6.0-8.fc19 mate-utils-1.6.0-8.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mate-utils-1.6.0-8.fc18 mate-utils-1.6.0-8.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mate-utils-1.6.0-8.fc20 Package mate-utils-1.6.0-8.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mate-utils-1.6.0-8.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15955/mate-utils-1.6.0-8.fc20 then log in and leave karma (feedback). mate-utils-1.6.0-8.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. mate-utils-1.6.0-8.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. mate-utils-1.6.0-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |
Based on this suspicious output mate-dictionary from mate-utils provides libmatedict.so.6()(64bit) mate-utils from mate-utils provides libmatedict.so.6()(64bit) required by: mate-dictionary-devel-1.6.0-7.fc20.x86_64 required by: mate-utils-devel-1.6.0-7.fc20.x86_64 I've only verified in koji that lots of files are included in both sub-packages. Even the descriptions overlap.