Producing native packages from DSSS builds is already on "the list."

And DSSS provides a large number of advantages that aren't in native packages, simply because DSSS is tailored towards D.

I completely understand that issues with pervasiveness of different installation systems and platforms, it's the core of my current job, and I designed DSSS with the forethought that it would at least as often be used simply to force fairly consistent installs for packaging systems as it would be for its net feature.  I've been trying to stress that the net feature is /not/ its primary feature, but certain parties who shall remain nameless have pressured me into bringing that future to the forefront.

 - Gregor Richards

Brad Roberts wrote:
> While DSSS is a great product in the vein of cpan and its ilk and I don't want to diminish it's value, but for most unix flavors, there's native packaging mechanisms that are preferred by the masses.
> 
> Explicitly stated:
>   for freebsd, ports is king
>       debian, .deb's and the various front ends is where it's at
>       redhat, .rpm and yum
>       windows, uh... installshield?  I dunno.. not my playground
>       etc...
> 
> My primary experience is with debian.  There there's wrappers around cpan to facilitate creation of .deb from a cpan package should it not happen to be already officially packaged up (an extreme rarity).  As a maintainer of more systems than I care to, I value the uniformity that using a single package management system brings.
> 
> So.. what would really go a long way, would be a way to easily create native package for various platforms and a repository to be populated.  What would then work well would be for there to be a single 'starter' package for D development:  probably a dmd/gdc installer + a hook to register the native repository with the native install system (for debian this would be adding a line to the /etc/apt/sources.list file).
> 
> DSSS could then mutate to a system for building and producing the artifacts to go into the repository, maybe.
> 
> Anyway.. food for thought.
> 
> Later,
> Brad
> 
> On Wed, 15 Nov 2006, Jesse Phillips wrote:
> 
> 
>>Date: Wed, 15 Nov 2006 10:37:53 -0800
>>From: Jesse Phillips <Jesse.K.Phillips+Digitalmars@gmail.com>
>>Reply-To: digitalmars.D <digitalmars-d@puremagic.com>
>>To: digitalmars-d@puremagic.com
>>Newsgroups: digitalmars.D
>>Subject: Re: Last DMD made me truly breathless -- for the wrong reasons
>>
>>DSSS would make a good distro for dmd/build. May not be feasible now,
>>but some day.
>>
>>Georg Wrede wrote:
>>
>>>My experiences last night
>>>
>>>
>>>I've been doing production work in D for some six months now. Therefore
>>>I have been a bit reluctant to actually download the latest versions for
>>>testing, we've settled on 0.166 on Linux, and want to stay with it for
>>>some time past D 1.0.
>>>
>>>Yesterday I couldn't resist, so I installed .174 on my w2k laptop -- and
>>>I was in for a major jolt:
>>>
>>>Idly browsing dmd/bin I found that one of the exes actually had an icon.
>>>So I double-clicked it, and guess what, a simple wysiwyg GUI editor pops
>>>up! Wow, now we can make simple GUI apps right out of the box! And I
>>>found a small and nice text editor already configured for D there, too!
>>>
>>>How come I've missed the buzz? Well, I guess D development is really
>>>putting on an exponential speed. Hoy contenders, resistance is futile!
>>>
>>>Some research this morning revealed the day-after: I must have
>>>downloaded DFL in the spring and forgotten to erase the dm and dmd
>>>hierarchies before unzipping. Oh well, it's the small things, like always.
>>>
>>>
>>>Some observations
>>>
>>>While I actually believed I was using this "shrink-wrap-DMD", I had
>>>several different feelings about it:
>>>
>>> - wow, D is leaping forward -- where will we be in six months?!!
>>> - unfair to only provide GUI stuff for Windows
>>> - later it felt ok, since most D users are on Windows anyway
>>> - Walter's really out to impress the crap out of folks
>>>
>>>After my bitter fall to ground, I felt:
>>>
>>> - why not?
>>> - some freebies in there make it feel polished, and "bigger"
>>> - ok, it's not Eclipse, but it could be touted as "a largish example"
>>> - OTOH, it must be awkward for Digital Mars:
>>>    - quality issues
>>>    - rights issues
>>>    - the hassle, maintenance, support...
>>>    - uncertainty about continued support from the app authors
>>>    - upgrades syncing, especially waiting for the apps to catch up!
>>>    - fighting with folks about who's stuff to include
>>>
>>>
>>>Things learned
>>>
>>>Obviously Walter can't be burdened with all this. So, what's left?
>>>IMHO, we could re-examine the idea about there being "D distros".
>>>
>>>We could have a few distros, each trying to be more user friendly, more
>>>outa-the-zip usable, and later distros for specific things, like games
>>>development, office stuff development, systems stuff, etc. If Linux
>>>seems to prosper with it, then I see no reason why D couldn't.
>>>
>>>The DMD license could deny charging for such distros. At the same time
>>>the text would recommend contacting DM, "for very reasonable deals" on
>>>for-profit distribution, including book-sleeve CDs.
>>>
>>>This way Walter could concentrate on exactly what he's doing right now,
>>>and what he's better at than anybody else: rocketing D to places where
>>>no language has gone!
>>

BRING THE FUTURE TO THE FOREFRONT!!!

Tpyo. s/future/feature/

Gregor Richards wrote:
> remain nameless have pressured me into bringing that future to the 

Gregor Richards wrote:
> Producing native packages from DSSS builds is already on "the list."
> 
> And DSSS provides a large number of advantages that aren't in native packages, simply because DSSS is tailored towards D.
> 
> I completely understand that issues with pervasiveness of different installation systems and platforms, it's the core of my current job, and I designed DSSS with the forethought that it would at least as often be used simply to force fairly consistent installs for packaging systems as it would be for its net feature.  I've been trying to stress that the net feature is /not/ its primary feature, but certain parties who shall remain nameless have pressured me into bringing that future to the forefront.

For what it's worth, Windows doesn't really have a package management feature like most other operating systems, so an automated version tracking/download system there would be a great asset, even if the final step was just to launch an installer app.  As for installers, Installshield is a fairly expensive piece of software, but there is a lightweight installer generator available from Microsoft:

http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/default.aspx

I haven't tried it yet so I can't comment on its quality, but you can't beat free.


Sean

Sean Kelly wrote:
> Gregor Richards wrote:
>> Producing native packages from DSSS builds is already on "the list."
>>
>> And DSSS provides a large number of advantages that aren't in native packages, simply because DSSS is tailored towards D.
>>
>> I completely understand that issues with pervasiveness of different installation systems and platforms, it's the core of my current job, and I designed DSSS with the forethought that it would at least as often be used simply to force fairly consistent installs for packaging systems as it would be for its net feature.  I've been trying to stress that the net feature is /not/ its primary feature, but certain parties who shall remain nameless have pressured me into bringing that future to the forefront.
> 
> For what it's worth, Windows doesn't really have a package management feature like most other operating systems, so an automated version tracking/download system there would be a great asset, even if the final step was just to launch an installer app.  As for installers, Installshield is a fairly expensive piece of software, but there is a lightweight installer generator available from Microsoft:
> 
> http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/default.aspx
> 
> I haven't tried it yet so I can't comment on its quality, but you can't beat free.
> 
> 
> Sean

I haven't used Visual Studio Installer (the above link) but I have used the Nullsoft Scriptable Install System:

http://nsis.sourceforge.net/

It's also free and is quite nice to use.  Maybe not as supported as the Microsoft solution in the long term, though :P

-Dave

/me votes for DSSS GUI + integrated installer (based on per package scripts coming with the package) \o/

Sean Kelly wrote:
> Gregor Richards wrote:
>> Producing native packages from DSSS builds is already on "the list."
>>
>> And DSSS provides a large number of advantages that aren't in native packages, simply because DSSS is tailored towards D.
>>
>> I completely understand that issues with pervasiveness of different installation systems and platforms, it's the core of my current job, and I designed DSSS with the forethought that it would at least as often be used simply to force fairly consistent installs for packaging systems as it would be for its net feature.  I've been trying to stress that the net feature is /not/ its primary feature, but certain parties who shall remain nameless have pressured me into bringing that future to the forefront.
> 
> For what it's worth, Windows doesn't really have a package management feature like most other operating systems, so an automated version tracking/download system there would be a great asset, even if the final step was just to launch an installer app.  As for installers, Installshield is a fairly expensive piece of software, but there is a lightweight installer generator available from Microsoft:
> 
> http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/default.aspx
> 
> I haven't tried it yet so I can't comment on its quality, but you can't beat free.
> 
> 
> Sean

Anders F Björklund wrote:
> Georg Wrede wrote:
> 
>> We could have a few distros, each trying to be more user friendly,
>> more outa-the-zip usable, and later distros for specific things, like
>> games development, office stuff development, systems stuff, etc. If
>> Linux seems to prosper with it, then I see no reason why D couldn't.

With Linux (and Unix and BSD and Mac), the distros I'm talking about should of course adhere to existing standards. That is, be packaged as .rpm files (for RedHat) and whatever else is customary on the other 'nixes. This is obvious.

On Windows, I believe the distros should essentially be self installing packages. Whether they are created with Install Shield or hand-made, that is mainly the distro creator's head ache. The customer really cares only about ease and reliability. The most primitive distros could simply be .zip archives that contain a .bat file that the readme tells you to run once.

> Linux is Free Software under the GPL, though ? Then again, so is GDC...
> I think that a D "distro" is a great idea, but would prefer GNU GPL+FDL.

Of course that would be the cleanest alternative. And no doubt, if ever this distro thing gets off ground, surely there will be at least one that combines GDC with a bunch of GPL+FDL stuff only.

>> The DMD license could deny charging for such distros. At the same time the text would recommend contacting DM, "for very reasonable deals" on for-profit distribution, including book-sleeve CDs.
> 
> AFAIK, the DM license forbids all re-distribution of the DMD software ?
> So if I made a friendly installer for DMC/DMD, I couldn't distribute it.

The point of my post was to encourage Walter to slightly adjust this single aspect of the DM license, for this very purpose.

If that gets done, then we'd have a Darwinian forest of D-distros, the best of which would survive. Not to mention the variety and buzz and controversy between them, all of which would ultimately help spread the word about D's existence in the first place.

    Think about it: D development has become almost exponential.
    At the same time, the current "distro", as seen from end-user
    perspective, is exactly the same as the one you got 4 years
    ago. Really. What if we got this distro development speed to
    match that of D itself? For comparison, imagine D a year ago
    and compare with today. Then imagine the current "D distro"
    and imagine one year from now, with the same speed of
    development. "You aint seen nothin yet" _should_ be the
    motto here.

Even if some distro is plain crap, it wouldn't harm D's (or DM's or DMD's, or the community's) public image, folks would simply dump it and find a better one. This is no big deal, it happens in the consumer market all the time, and even when we are at the TV remote control, or when we choose what to eat this time.

The following paragraph:

> The DMD license could deny charging for such distros. At the same time the text would recommend contacting DM, "for very reasonable deals" on for-profit distribution, including book-sleeve CDs. 

was there to show how this can be done without losing credibility amongst the potential for-profit parties. I honestly don't expect DM to make any money from repackaging licenses, but the statement obviously still has to be there. (I don't expect DM to make revenue directly with DMD any other way either. In a world of free as beer compilers, I just don't think so. Any money Walter makes from D will probably be indirect, like consultation, paid articles, programming, seminars, books, etc.)

Against this background, it suddenly doesn't seem like such a far fetched idea to let indie distros flourish.

---

But there's another alternative too:

Walter might license some individuals directly.

Georg Wrede wrote:

> With Linux (and Unix and BSD and Mac), the distros I'm talking about should of course adhere to existing standards. That is, be packaged as ..rpm files (for RedHat) and whatever else is customary on the other 'nixes. This is obvious.

We have RPMs for RedHat/Fedora, DEBs for Debian/Ubuntu, an ebuild for
Gentoo, and I think there is a port for FreeBSD somewhere as well...

They will even handle installing the old "compat" libstdc++.so it needs,
upgrade the configuration and handle upgrades + all such other niceties.

> On Windows, I believe the distros should essentially be self installing packages. Whether they are created with Install Shield or hand-made, that is mainly the distro creator's head ache. The customer really cares only about ease and reliability.

I think the Nullsoft installer system (NSIS) is great, and recommend it.
It's easy to use, open source, and creates low overhead installers EXEs.

For Mac OS X one can use the built-in Installer.app and create similar
installer PKGs, even if it is not as good as the Linux package managers.

> The most primitive distros could simply be .zip archives that contain a .bat file that the readme tells you to run once.

That would be the Digital Mars distribution then. Well, minus .bat ;-)
Unfortunately the .tgz version, with UNIX linefeeds, is still missing...

For the add-on libraries, it looks like DSSS could be a good thing -
I only need to get the new GDC, the new Bud and DSSS all packaged up.

> Of course that would be the cleanest alternative. And no doubt, if ever this distro thing gets off ground, surely there will be at least one that combines GDC with a bunch of GPL+FDL stuff only.

There are two such GDC "distros", for Mac and Win, maybe one for Linux.
But there isn't very much bundled except the D compiler at the moment.

Future releases will feature more import modules and more documentation,
this is something that has been planned all along. Just not completed.

>> AFAIK, the DM license forbids all re-distribution of the DMD software ?
>> So if I made a friendly installer for DMC/DMD, I couldn't distribute it.
> 
> The point of my post was to encourage Walter to slightly adjust this single aspect of the DM license, for this very purpose.

There are ready-made installer templates, if Walter wants to use them ?
(I know that I have "donated" a specfile for RPM and a script for NSIS)
So there are no technical reasons why there aren't any DMD installers ?
It's just that Walter prefers the archives, and distributing it himself.

If the DMD compiler and D specification were re-distributable, then we could help out. But since they're not, we can only wait until they are ?
It's not that it is *hard* to go to ftp.digitalmars.com for DMD or to www.digitalmars.com for D, but it cannot be compared with being Free...

--anders

Anders F Björklund wrote:
> 
> I think the Nullsoft installer system (NSIS) is great, and recommend it.
> It's easy to use, open source, and creates low overhead installers EXEs.

I gave this a glance yesterday and it looks great.  Must better than Installshield for the average case.


Sean

Sean Kelly wrote:
> Anders F Björklund wrote:
> 
>>
>> I think the Nullsoft installer system (NSIS) is great, and recommend it.
>> It's easy to use, open source, and creates low overhead installers EXEs.
> 
> 
> I gave this a glance yesterday and it looks great.  Must better than Installshield for the average case.

My 2 cents is that InnoSetup is the best for simple cases where you don't need much custom logic, you're just installing some files, and maybe setting a few environment variables.

NSIS is best if you need very specialized custom behavior like an internet-aware installer or something like that.  But it's a more complicated than InnoSetup to use for the simple cases.  For instance With NSIS, you have to provide a list of all files to install, *and* all files to uninstall (even though they are usually pretty much the same).  NSIS's way is more general, but more tedious.

--bb

I'm all for InnoSetup too , with its pascal type scripting language its also capable of some pretty complicated installs, if you need it.

Theres also form designers for InnoSetup ( free ! ) , and other fun plugins as well.

Charlie

Bill Baxter wrote:
> Sean Kelly wrote:
>> Anders F Björklund wrote:
>>
>>>
>>> I think the Nullsoft installer system (NSIS) is great, and recommend it.
>>> It's easy to use, open source, and creates low overhead installers EXEs.
>>
>>
>> I gave this a glance yesterday and it looks great.  Must better than Installshield for the average case.
> 
> My 2 cents is that InnoSetup is the best for simple cases where you don't need much custom logic, you're just installing some files, and maybe setting a few environment variables.
> 
> NSIS is best if you need very specialized custom behavior like an internet-aware installer or something like that.  But it's a more complicated than InnoSetup to use for the simple cases.  For instance With NSIS, you have to provide a list of all files to install, *and* all files to uninstall (even though they are usually pretty much the same).  NSIS's way is more general, but more tedious.
> 
> --bb