[Tinyos Core WG] support/bin

[David Gay]

On 5/18/07, Philip Levis <pal at cs.stanford.edu> wrote:
> On May 18, 2007, at 3:55 PM, David Gay wrote:
>
> > On 5/18/07, Philip Levis <pal at cs.stanford.edu> wrote:
> >> Net2 met today, and the folks from JHU are ready to check in Deluge
> >> for 2.0. There's one blocking item, which is the decision of whether
> >> to put  the command-line tools in tools/ or support/. Since they are
> >> command line tools, they benefit from being separate from support/
> >> sdk/
> >> python/blah/blah. The conclusion was that we need a support/bin,
> >> which has end-user scripts. tos-mviz would probably migrate there.
> >>
> >> Are there any objections to creating a support/bin?
> >
> > Didn't get round to answering in the "private" thread. My issue here
> > is that having a support/bin, installed somehow when you install the
> > rpm, gets in the way of either:
> > - a relocatable rpm as we have now
> > - or, actually being an rpm-kind of thing which tracks groups of
> > installed files (to make it relocatable and have tools in support/bin,
> > you end up needing to do some magic in post-install scripts to put the
> > files somewhere, or to mess with the user's path which is even worse)
> >
> > What's the real problem in having them in tools? Version dependency
> > issues can be addressed by placing appropriate requirements on
> > tinyos-tools in the tinyos rpm.
> >
> > I really do think life is easier with a "real rpm" (tinyos-tools) and
> > a "convenient tarball-like thing" (tinyos)
>
> Well, except that the tarball-like thing has stuff like support code,
> like tinyos.jar...

However that stuff lives in the tos hierarchy when in use (unlike
command-line tools).

> My motivation for support/bin was to be able to separate tools RPM
> distributions from tinyos RPM distributions. The idea that a change
> to Deluge that requires a change to its scripts requires a tools RPM
> update seems like a pain; better to keep changes localized. Now that
> we're moving to more frequent 2.0 releases, I'd like to avoid having
> to release tools nearly as often and go through the testing cycle for
> them.
>
> I'm willing to stick with tools/ for now just because it doesn't
> change anything;we can later figure out if these are issues in
> practice or tools/ is fine.

My motivation here is that we used to do a single combined tools+tos
rpm for 1.x, and it was a pain. Having 2 rpms seems a lesser pain so
far. If we're going to go back to having some tools in the tos rpm,
we'll end up with the worst of both (two rpms + the support headache).

David