Spec URL: http://people.atrpms.net/~athimm/fedorasubmit/vtk/vtkdata.spec SRPM URL: http://people.atrpms.net/~athimm/fedorasubmit/vtk/vtkdata-5.0.1-3.at.src.rpm Description: Example data file for VTK Expected rpmlint output: W: vtkdata no-documentation E: vtkdata script-without-shellbang /usr/share/vtkdata-5.0.1/Data/usa.vtk E: vtkdata wrong-script-end-of-line-encoding /usr/share/vtkdata-5.0.1/Data/usa.vtk E: vtkdata script-without-shellbang /usr/share/vtkdata-5.0.1/Data/cellsnd.ascii.inp E: vtkdata script-without-shellbang /usr/share/vtkdata-5.0.1/Data/thio3xx.xyz rpmlint detects some non-scripts as scripts.
Spec URL: http://people.atrpms.net/~athimm/fedorasubmit/vtk/vtkdata.spec SRPM URL: http://people.atrpms.net/~athimm/fedorasubmit/vtk/vtkdata-5.0.1-4.at.src.rpm * Wed Jul 19 2006 Axel Thimm <Axel.Thimm> - 5.0.1-4 - Fix some permissions. See bug 199405 comment 1, rpmlint is much cleaner now.
2 issues: - Your buildroot. - Why are you installing to %{_datadir}/%{name}-%{version} instead of %{_datadir}/vtk or %{_datadir}/vtkdata?
One of recent features of vtk was to allow for several concurrent vtkdata installs due to user demand and be able to switch back and forth. I don't intend to ever have a second package coinstall a different data set, but if the user wants to do so, I'd like to avoid any conflicts and be verbose on filesytem level about what is actually on the system.
(In reply to comment #3) > One of recent features of vtk was to allow for several concurrent vtkdata > installs due to user demand and be able to switch back and forth. A versioned data dir would be useful if there is a strong dependency between application and application data, and if the application is supposed to be installed in parallel. But I don't see how this applies here. > I don't intend to ever have a second package coinstall a different data set, but > if the user wants to do so, I'd like to avoid any conflicts and be verbose on > filesytem level about what is actually on the system. I regret having to say this, but I refuse to approve this package in its current shape.
> (In reply to comment #3) > > One of recent features of vtk was to allow for several concurrent vtkdata > > installs due to user demand and be able to switch back and forth. > A versioned data dir would be useful if there is a strong dependency between > application and application data, and if the application is supposed to be > installed in parallel. > > But I don't see how this applies here. How strongly the application and its data are tied varies in vtk's past. Currently it is quite high, as both got a simultaneous minor release. (In reply to comment #4) > > I don't intend to ever have a second package coinstall a different data set, > > but if the user wants to do so, I'd like to avoid any conflicts and be > > verbose on filesytem level about what is actually on the system. > > I regret having to say this, but I refuse to approve this package in its > current shape. Now I'm going to break out in tears ;) Ignoring actual user demand which is acknowledged by upstream development and even implemneted isn't really constructive.
(In reply to comment #5) > > (In reply to comment #3) > How strongly the application and its data are tied varies in vtk's past. > Currently it is quite high, as both got a simultaneous minor release. Either data files are subpackages of an application, then they should go to below an application owned directory (data as internal implementation detail) or they are independent of the application, then they should go to outside of the applications directories. If they require a certain API, such data should go to API versioned directories. In none of these cases parallel installation of data files makes any sense. Also, upstream ships its data in an unversioned directory, which I read as a strong indication of them not wanting a versioned directory. > Ignoring actual user demand which is acknowledged by upstream development and > even implemneted isn't really constructive. 1. Show us an URL were upstream explicitly says so. I searched their web site and could not find any such statement. 2. User demand? Whose?
http://dl.atrpms.net/all/vtkdata-5.0.3-6.at.src.rpm http://dl.atrpms.net/all/vtkdata.spec * Sun Apr 15 2007 Axel Thimm <Axel.Thimm> - 5.0.3-6 - Update to 5.0.3.
GOOD: + spec is simple, legible, follows naming guidelines, etc. + rpmlint reports only a few ignore-able warnings: W: vtkdata no-%prep-section W: vtkdata no-%build-section W: vtkdata no-documentation + builds in mock on FC6 x86_64 + permissions and dir ownership looks good to me + license matches that of VTK -- good NEEDSWORK: + the srpm in comment #8 seems to be a broken link so I could not verify that source matches upstream -- but I do not consider that to be a blocker as I was able to build a working package from the spec file (which was not a broken link) In regards to comment #6, I don't think it matters whether the directory is versioned or not. If Axel would like to version it then I think that's OK -- I just don't see how it voilates any of the guidelines or does any real harm. APPROVED.
Hey Ed. According to the current review procedures the fedora-review flag should be set to + to approve. Can you go ahead and set that?
Ooops! Thank you for pointing that out. :-)
Thanks, Ed! New Package CVS Request ======================= Package Name: vtkdata Short Description: Example data file for VTK Owners: Axel.Thimm Branches: F-7 FC-6 FC-5
cvs done.
vtkdata-5.0.3-6.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
The only thing I don't really like is the disttag in the name. Even though I'm a disttag fan this package is distro-agnostic and should be used w/o rebuilding on any other distro. But that isn't reason enough to rebuild this package and repush it, I'll just drop the disttag on the next update. (FWIW I forgot to remove the disttag, as the disttag is used at ATrpms to denote repotag&disttag and is set to only have a repotag in this case) Thanks Ed for reviewing and Kevin for cvs work :)
vtkdata-5.0.3-6.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Package Change Request ====================== Package Name: vtkdata New Branches: el6 Owners: orion InitialCC:
Git done (by process-git-requests).