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

Re: intent to package TETware and VSX-PCTS from TOG



On Tue, 12 Jan 1999, Marcus Brinkmann wrote:

> On Tue, Jan 12, 1999 at 09:47:27AM -0800, Stephen Zander wrote:
> > >>>>> "Dale" == Dale Scheetz <dwarf@polaris.net> writes:
> >     Dale> The directories $TET_ROOT/bin, $TET_ROOT/lib, $TET_ROOT/src,
> >     Dale> etc...  contain the TETware binaries, libraries, sources,
> >     Dale> etc... specifically to keep them separate from the system to
> >     Dale> be tested.
> > 
> > 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?

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

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

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

On the other hand, I may be surprised to find that the POSIX test suite
complains about whatever location is finally decided ;-)

Please don't shut up...

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


Reply to: