Tango updater for DMD/Win32

• What is meant with unattended install here? Just hit/type start and it completes?
• With config files I assume you mean dmd.conf/sc.ini - are there others?
• I can't see that leaving imports alone is our job? If you make changes to the import tree, then you should keep your version somewhere else and reflect that in your compiler config. Not updating the import tree at all may be an option, although it don't make much sense, since updating the runtime library may require an update of the Tango import tree.

I'm putting this one at 1.0 for now, and saying it's for DMD/Win32. Different ppl will most likely be involved on the different platforms. Tickets for those will be created as needed.

Excellent questions. Thanks for being so receptive to the idea. :)

Replying to larsivi:

* What is meant with unattended install here? Just hit/type start and it completes?

The idea is that a fully-capable network installer might ask for some confirmation as to what version you wish to install (stable, development, tip, whatever), and ask for a "yes or no" kind of confirmation before installing. I was thinking more within the power-user context of just typing "tango-update -v0.99B" and would just install that version w/o asking if it's okay.

Another way to go is to simply code the thing up as simple and possible, and simply fetches the most recent release, no matter what.

* With config files I assume you mean dmd.conf/sc.ini - are there others?

I think that's it. The idea is to not clobber any path information explicit to the user's install. For instance, when I used to update DMD, I would extract everything from dmd.zip except for sc.ini.

* I can't see that leaving imports alone is our job?

I was talking about imports other than the tango tree. Like if I had DDL installed under Tango/import, I'd expect the updater to only touch Tango/import/std and Tango/import/tango, and leave Tango/import/ddl alone.

I'm putting this one at 1.0 for now, and saying it's for DMD/Win32. Different ppl will most likely be involved on the different platforms. Tickets for those will be created as needed.

Windows seems to have the weakest policy in this area, so that makes a lot of sense.

Replying to pragma:

* I can't see that leaving imports alone is our job?

I was talking about imports other than the tango tree. Like if I had DDL installed under Tango/import, I'd expect the updater to only touch Tango/import/std and Tango/import/tango, and leave Tango/import/ddl alone.

Hmm, both (afaik) windows and linux installers install the imports to <PREFIX>/import/tango . The linux installer currently works by nuking the tango dir and all it's contents (tango, std, object.di) because that is simplest and easiest for keeping away cruft. What you propose would then mean that you put ddl inside that tango dir in which case you would lose it with the current setup (it's no real problem removing the components inside tango btw, may do that instead, unless of course someone put tangobos there, in which case that would be removed too). Basically, what I'm getting at, is that if you manually put your other imports at the same place as the tango imports, then you're probably not a typical user for an installer in the first place? And if you do that, then you might as well add your own -Isomething to your config file?

Replying to myself here - you will get your will whenever this is implemented, import/tango/ for Tango compatible libs. Feel free to speed up the process with a patch :)

Hi Eric

Sounds good! We'd talked in the past of something similar, with a folder structure of this nature:

import/
  tango/
  ddl/
  mango/
  swt/
  etc.

where the tango folder has net/ io/ tex/ etc directly below it. This structure would necessitate only a single -I setting.

Sounds like a stripped down, and more specialized version of DSSS? I mean, it would presumably support Tango compatible libs, and perhaps hit a central registry server to find the location, status and configuration of various related packages? The compiler itself would be handled in a similar fashion, for all platforms?

Would be great if you were to write this ;)

Replying to kris:

Sounds like a stripped down, and more specialized version of DSSS? I mean, it would presumably support Tango compatible libs, and perhaps hit a central registry server to find the location, status and configuration of various related packages? The compiler itself would be handled in a similar fashion, for all platforms?

That's kind of where I was headed with this. DSSS works reasonably well for just "grab and go" installations, but it lacks finer package management. Being able to selectively upgrade, revert and remove are not "nice to have" features IMO.

Would be great if you were to write this ;)

I'll see what I can do - I might just branch DSSS (with the intent to contribute back) and go from there. There are already a few things I want to add to that project anyway.

I don't think this ticket should be kept in Tango's scope - I don't think DSSS has solved everything above yet, but I feel like closing this in any case. I think it makes more sense to have Tango packages that fit into other available systems, and/or if someone creates an updating installer, we'll be happy to accept the contribution.