[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Guidelines for creating subpackages?

> > First of all, vtk-devel at least pulls in vtk-python, vtk-tcl, vtk-qt,
> > tcl, tk, qt beyond packages that were already required by the base
> > system. Are these packages specific to developers? I doubt so.
> > Moreover, what you call developers are not necessarily hardcore
> > developers of the package under consideration, so it might be simple
> > people who just need/want to build an application based upon the VTK
> > toolkit.
> Though it is not easy to know by advance which binding they will need.

This argument applies to both runtime [needed to run the binary] and
development [needed to build the binary] packages and could rather be
understood as an argument -against- splitting runtime packages.

> > As a matter of fact, Fedora does not even include a single application
> > that uses any of vtk, vtk-python, vtk-qt, vtk-tcl [well, vtk-examples
> > and vtk-testing but that probably doesn't count].
> In fact paraview uses vtk, though for right reasons still uses an
> internal version, but hopefully one day will use the system vtk. But
> more generally you cannot predict which package will use which library 
> or binding. You have to package as if your library could be used even 
> if it is not currently. There are a lot of software that are still 
> not in fedora.

This is still no argument in favour of a monolithic development package
when there exist split runtime packages. The packager of a source RPM
always has to ensure that both requirements -and- build requirements
are defined correctly in the spec file. This usually even allows to
steer which bindings are enabled or disabled during the [autotools]
configure phase.
Btw, the reason for pointing out the absence of any package built against
vkt-* was that Warren had made a distinction between users and developers
which simply does not apply well to VTK in Fedora ..

> > Apart from using 3rd party binaries, any person interested in the vtk
> > package necessarily is what you call 'developer'. So, the term 'user'
> > essentially loses any meaning in this context.
> > Finally, the case of the plplot package shows that my initial request
> > is by no means exotic, and I maintain my point that it would be sign
> > of userfriendliness not to impose unneeded packages like the ones
> > enumerated above on a user of the vtk package.
> You mean plplot requires vtk-devel? Or plplot-devel requires vtk-devel?

Of course not. I had cited the plplot package as an example where no
monolithic development package but development subpackages corresponding
to runtime packages already do exist.

> Runtime fine grained dependencies are very desirable but devel fine
> grained dependencies are optional nad in the case of vtk, I think that
> it is best left to the packager, and I think that most vtk users expect
> all the binding to be there when installing vtk-devel.
> --
> Pat

Fine grained runtime dependencies are not very useful when development
packages pull them in altogether, thus effectively thwarting the whole
"Thinking" that most VTK users expect all the bindings is not what I would
call a strong point. I -am- a VTK user, and I have actually expressed
my discontent. So, the current score is rather 0:1!
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]