Dne 26.4.2011 15:20, Sascha Peilicke napsal(a):
On Tuesday 26 April 2011 14:52:10 you wrote:
Dne 26.4.2011 14:44, Sascha Peilicke napsal(a):
On Tuesday 26 April 2011 14:27:35 you wrote:
State of submit-request #68231 was changed by matejcik: new -> declined
Comment: please use %files -f INSTALLED_FILES when you can use --record-rpm,
instead of listing files by hand.
This is not a valid decline reason as this allow to build Python packages that work acros distros, because --record-rpm isn't available everywhere. However,
This is a valid reason because it's not a well-written spec. Do we have some public docs on what we currently consider a well-written spec with regards to Python packages?
i don't think we have a doc on what we consider a well-written spec in general, but we do have packaging guidelines and this spec is not following its spirit too well. I'd say it's more a case of using common sense - when you use --record-rpm, don't discard the result. General packaging guidelines have nothing to say on explicitness of file lists (which is probably a mistake that should be fixed), but i think we can agree that being overly explicit is not good for maintainability.
(perhaps guidelines for "good" specs vary between our teams? in that case, we should have some kind of discussion about what is and isn't appropriate for public repositories - or is there some kind of definite guideline published on wiki or anywhere?) Ok, seems like we don't.
Also, if we care about cross-distro compatibility, a valid reason for decline would be using "--record-rpm" at all because it would break the build on other distros. Yep, and I'd say this is reasonable as this is a major reason for using the Build Service. Personally, I make sure that (most) of my Python packages work on every distro (well, except the DEB-based ones currently) we offer.
just thought of something: when building Python packages in buildservice, they're built with our python that does have --record-rpm capability. And because it only matters at build-time, it should be valid to use it for cross-distro packages. Or does this work differently?
Currently this isn't all too visible as we only enable a limited set for devel:languages:python and I don't have the balls to enable more distros because a lot of packages need love there :-)
instead of explicitly listing each and every file, the following would suffice:
%files %defattr(-,root,root,-) %{python_sitearch}/*
true. i would argue that this is still bad practice - in this particular case, file listing should be this:
%defattr(-,root,root,-) %{python_sitearch}/enthought %{python_sitearch}/Traits-%{version}-py*.egg-info %{python_sitearch}/Traits-%{version}-py*-nspkg.pth
You are right, but egg-info stuff isn't always generated and most of the time there's no relation between the package name and what ends up in %{python_sitearch}. This is an issue for auto-generating packages (e.g. with py2pack), therefore I tend to favor the first approach (even if it is messy).
Maybe there should be a guideline to use your py2pack unless there is reason to do it manually. How do your autogenerated packages handle updating?
BTW. For py2pack, I currently use the following spec template: https://github.com/saschpe/py2pack/blob/master/py2pack/templates/opensuse.sp...
If you agree, we may continue this discussion on opensuse-packaging.
yes, let's. regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org