Whoops - my apologies - I misunderstood the initial email. FWIW, a few thoughts...
I gave this matter some thought when I first installed TinyOS and at the time was thinking that a chroot environment might be best in terms of long-term stability and preventing conflicts. However, there is some setup of the chroot itself that could become fairly involved. You'd probably want to bind mount /opt inside the chroot so it looked the same both inside and outside. (And if you're going to that much trouble, it might be easier for users to create a VMware appliance like the one the SOS team produced.) Regarding whether or not it's in the scope of package maintenance, I'd agree that it's not really a good idea to be moving stuff around. If nothing else, you'll end up with differences between the instructions for RPM/cygwin users and the Debian/Ubuntu camp, which seems generally like a bad idea. However, you could use Conflicts: to prevent folks from even trying to install packages that contain file-level conflicts with other packages in the distribution. Beyond that, I'll have to think about it some more. tony leith wrote: > the package names already differentiate them from the other releases. > > unfortunately, the files themselves are located on the same path... > > ------ > processing /var/cache/apt/archives/avr-gcc-tinyos_3.4.3-2_i386.deb > (--unpack): > trying to overwrite `/usr/share/man/man1/avr-gcc.1.gz', which is also > in package gcc-avr > ------ > > to avoid this, i would have to move the folders around, and update any > references to them. > > i don't mind doing this, but is this out of the scope of package > maintenance, and wouldn't this break other things in the process? > > any thoughts? > > -leith > > > Philip Levis wrote: >> On Apr 13, 2007, at 8:52 AM, Tony Mancill wrote: >> >>> I'd suggest changing the name of the tinyos-specific AVR toolchain >>> packages. This will prevent the namespace collisions within the package >>> manager. If the managers of the Stanford repository aren't interested >>> in doing this, you can do it yourself. I don't remember the exact >>> syntax off the top of my head, but it goes along the lines of: >>> >>> * extract the current package files with dpkg -x pkg.deb >>> * extract the current package control info with dpkg -e pkg.deb >>> * update DEBIAN/control >>> * repack the deb using dpkg-deb -b >> >> I'll ask Leith (who maintains the repository). >> >> The core WG is generally pretty resistant to just tracking the most >> recent avr-gcc and msp430-gcc releases, as each one has its own bugs >> and problems. For example, the most recent avr-gcc handles inlining >> very differently than the one TinyOS uses, such that you have factors >> of three differences in binary sizes. >> >> There has been some talk about updating to a newer version, but my >> sense is that the push for this will be supporting new microcontrollers. >> >> Phil >> _______________________________________________ >> Tinyos-help mailing list >> [EMAIL PROTECTED] >> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> _______________________________________________ Tinyos-help mailing list [EMAIL PROTECTED] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
