Re: intent to package TETware and VSX-PCTS from TOG
On Tue, Jan 12, 1999 at 06:36:36PM -0500, Dale Scheetz wrote:
> On Tue, 12 Jan 1999, Marcus Brinkmann wrote:
> > >
> > > Why isn't something like the jdk structure apropriate? That would give
> > > you
> > >
> > > /usr/lib/TET/{bin,lib,src}
> >
> > For one, because we try to seperate architecture dependent stuff from
> > independent stuff in /usr/share.
>
> Then, if it is architecture dependent, it should go into /usr/share/TET3,
> while if it is independent of architecture, it should go into
> /usr/lib/TET3?
Correct. I don't know about how much (in kb) we talk about here, so if the
architecture independent files are not significant, it does not make sense
to put them on share, IMHO.
> > Secondly, I am not sure the jdk structure is appropriate itself, but
> > obviously it is in non-free and therefore does not need to comply completely
> > to Debian policy.
>
> I'm not so sure that it is a "good idea" to suggest that this is true.
> Non-free packages are maintained by Debian maintainers. This isn't RH
> contrib. There is no reason for a non-free package to deviate from policy
> on such an issue as file placement. Such violations can be reported as
> bugs just like any other package.
I completely agree with your sentiment, however, sometimes reality bites.
For example, if a path is hard coded in a binary we don't have the source
for. However, packages in non-free should be as policy compliant as
possible, IMHO.
> > Dale mentioned that they would "clutter up" the rest of the system. The same
> > could be said about Gnome or KDE, but we don't release their maintainers
> > from the policy either.
>
> Well, both Gnome and KDE provide binaries and libraries useful to other
> packages and to users in general. A system test bench isn't strictly a
> user app of any kind. The clutter created by placing binaries and
> libraries into "normal" locations is simply unnecessary, as it serves no
> other purpose than to satisfy the letter of a policy that doesn't apply
> here.
I understand.
> On the other hand, TETware may be useful to the Testing Group as the
> framework for package testing. In that case, there may be some rational
> for placing binaries and libraries "out in the system". It isn't clear to
> me whether TET can be operated in that fashion. It also isn't quite
> necessary. I don't see any reason why a "user" other than root can't run a
> specific package test or the whole suite, although there are certainly
> some tests that may require super user priviledge. None of this has much
> to do with the location of the binaries and libraries though ;-)
I wonder how the test suite are operated. I think the "main" app, which
starts and controls the tests, should be accessible by normal user (so user
joe can check if the sysadmin has a POSIX compliant system, at least for
parts which don't require root privs). However, the individual tests,
modules and whatever else don't need to be in standard locations, IMHO. Look
for example at perl, it has modules in lib/perl. GNU has libexec, maybe we
need this, too?
> > I don't know how the test files could interefere with the tested system, as
> > I don't know what binaries there are, how the testing works etc. I will
> > leave this decision to people who know what they are talking about so I shut
> > up now :)
> >
> Since what the tests might look for, or object to, is pretty open ended,
> depending on the type of test suite being run, there is good reason to not
> add components to the system unnecessarily.
I still don't have the picture how the test suite works (see above). Again,
if there are some central useful executables, I would like to see them in
bin (or symlinked/hardlinked to bin). Individual parts which are called by
the test suite would only clutter up and should be in lib or share.
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: