[Tinyos Core WG] support/bin

[Philip Levis]

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

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.

Phil