Bug 199406

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).