Bug 972237
| Summary: | Review Request: vcsh - Manage config files in homedirs via fake bare git repositories | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Corey Quinn <corey> |
| Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | corey, dridi.boukelmoune, echevemaster, i, kevin, notting, package-review |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-12 15:26:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 201449 | ||
|
Description
Corey Quinn
2013-06-07 22:08:38 UTC
It's worth pointing out that this is my first package, and I need a sponsor. Hi Corey: Initial comments: if you don't want ship the package to el5: - %clean is not needed - BuildRoot is not needed - cleaning of buildroot in %install is not needed - %defattr is not needed Thanks for the feedback! My current plan is to ship it to EL5, EL6, Rawhide, and current stable. Bearing that in mind, does any of that advice still apply? No, if you want to maintain this in one spec, still apply. If you create 2 or 3 spec for Fedora/EPEL5,6, you may delete these lines in Fedora spec. @Corey, in order to get a willing sponsor, you should participate in a few of informal reviews > - %defattr is not needed True, and it isn't needed for EL5 anymore either, because RPM is new enough. It can be dropped from the spec file. > %{_docdir}/vcsh/README.md > %doc LICENSE CONTRIBUTORS changelog This is somewhat unfortunate, because it creates two different doc dirs and an additional "unowned" directory: $ rpmls -p vcsh-1.3-1.fc19.noarch.rpm|grep doc drwxr-xr-x /usr/share/doc/vcsh-1.3 -rw-r--r-- /usr/share/doc/vcsh-1.3/CONTRIBUTORS -rw-r--r-- /usr/share/doc/vcsh-1.3/LICENSE -rw-r--r-- /usr/share/doc/vcsh-1.3/changelog -rw-r--r-- /usr/share/doc/vcsh/README.md -rw-r--r-- /usr/share/doc/vcsh/hooks => /usr/share/doc/vcsh is not included. Even if it may sound pedantic, it would look better, if all doc files were put into the same dir. https://fedoraproject.org/wiki/Packaging:UnownedDirectories https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership > %{_datadir}/zsh A comment in the spec file would be very good here, because this line includes directories, which belong into the zsh package. That's based on the following guideline: https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function A more readable notation for inclusion of a full directory tree uses adds a trailing slash, btw: %{_datadir}/zsh/ > /usr/share/zsh/site-functions/vendor-completions/_vcsh This is the same file as /usr/share/zsh/site-functions/_vcsh and no other package owns that directory already, so this may need a closer look during review. $ repoquery --whatprovides /usr/share/zsh/site-functions/vendor-completions $ > install -D -m 0644 _vcsh %{buildroot}%{_datadir}/zsh/site-functions/_vcsh https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps > mv %{buildroot}%{_datadir}/zsh/vendor-completions > %{buildroot}%{_datadir}/zsh/site-functions Since spec files are scripts, preferably one would comment on why this installed directory is moved. Hi, Are you still interested in this? Hi, I've started packaging vcsh on my own and ended up merging my work with what's already been done here :). It's also based on a more recent version from a couple days ago. I've taken care of packaging issues with a patch I haven't sent to the upstream, because the upstream project apparently maintains separate branches for packaging. So the patch would probably not land in the master branch. Source RPM and SPEC: https://bitbucket.org/dridi/fedora_packages/downloads So, it's been a month... https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews It's been a little more than a month and a week, I'll submit a new review request. I have submitted the new review request. *** This bug has been marked as a duplicate of bug 1018492 *** Looks like this was taken care of ages ago; sorry for my going dark! |