February 17, 2013
On Sun, 17 Feb 2013 16:13:47 +0100
"Dicebot" <m.strashun@gmail.com> wrote:
>
> After all, as far as I am aware, Windows gets a package manager in form of application store in last released version, doesn't it?

That doesn't remotely count as a real package manager.

(Then again, there isn't much in Win8 that counts for half a damn...And that's coming from a Windows user.)

February 17, 2013
On Sun, 17 Feb 2013 15:40:25 +0100
"Dicebot" <m.strashun@gmail.com> wrote:
>
> Packaging is best done (and should be) by OS package manager, not hundreds of languages-specific managers. Good language package manager in my opinion is just an information source for OS package builders.

I'm not real big on the idea of OS package managers. Not when Unix is in the picture anyway. I'm getting really fed up with software that has a "download / install" webpage populated with totally different instructions for an endless, yet always incomplete, list of Linux variants. And *maybe* BSD. And then on top of that, the poor *project* maintainers have to maintain all of that distro-specific cruft. Unless they're lucky and the project is big enough that the ditro maintainers are willing to waste *their* time converting the package into something that only works on their own distro.

I believe I can sum up my thoughts with: "Fuck that shit."

February 17, 2013
On Sunday, 17 February 2013 at 21:32:15 UTC, Nick Sabalausky wrote:
> On Sun, 17 Feb 2013 15:40:25 +0100
> "Dicebot" <m.strashun@gmail.com> wrote:
>>
>> Packaging is best done (and should be) by OS package manager, not hundreds of languages-specific managers. Good language package manager in my opinion is just an information source for OS package builders.
>
> I'm not real big on the idea of OS package managers. Not when Unix is
> in the picture anyway. I'm getting really fed up with software that has
> a "download / install" webpage populated with totally different
> instructions for an endless, yet always incomplete, list of Linux
> variants. And *maybe* BSD. And then on top of that, the poor *project*
> maintainers have to maintain all of that distro-specific cruft. Unless
> they're lucky and the project is big enough that the ditro maintainers
> are willing to waste *their* time converting the package into something
> that only works on their own distro.
>
> I believe I can sum up my thoughts with: "Fuck that shit."

In perfect world that software should have only one download link - to sources. Habit to get stuff from some probably official web pages is Windows habit. I have no idea why .deb and .rpm are provided so often, have never used a single one. Probably habit again.

Then, if your project is small, it is in your interest to maintain packages for distros you want (minimal efforts comparing to software maintenance itself). If it is big, someone will be willing to do it for you. Simple and works naturally better with bigger user base.

In return you get one single way to get software from people you may somewhat trust and sane dependency tracking. Beats anything for me and recent move towards various repo-like "stores" only proves it.
February 17, 2013
On Sunday, 17 February 2013 at 21:19:42 UTC, Nick Sabalausky wrote:
> On Sun, 17 Feb 2013 16:13:47 +0100
> "Dicebot" <m.strashun@gmail.com> wrote:
>>
>> After all, as far as I am aware, Windows gets a package manager in form of application store in last released version, doesn't it?
>
> That doesn't remotely count as a real package manager.
>
> (Then again, there isn't much in Win8 that counts for half a
> damn...And that's coming from a Windows user.)

What are the limitations then? I am only run-by Windows user, so it was actually a question.
February 17, 2013
On Sunday, 17 February 2013 at 14:40:26 UTC, Dicebot wrote:
> Packaging is best done (and should be) by OS package manager, not hundreds of languages-specific managers. Good language package manager in my opinion is just an information source for OS package builders.

D does not lend itself well to OS-level packaging, because different compilers as well as different versions of the same compiler will not be binary-compatible in the foreseeable future.

I think any D package management tool needs to be able to handle multiple coexisting compiler configurations, or at least allow being used for multiple installation (similar to RubyGems and rbenv/rvm).

David

February 18, 2013
On Sun, 2013-02-17 at 16:32 -0500, Nick Sabalausky wrote: […]
> I'm not real big on the idea of OS package managers. Not when Unix is in the picture anyway. I'm getting really fed up with software that has a "download / install" webpage populated with totally different instructions for an endless, yet always incomplete, list of Linux variants. And *maybe* BSD. And then on top of that, the poor *project* maintainers have to maintain all of that distro-specific cruft. Unless they're lucky and the project is big enough that the ditro maintainers are willing to waste *their* time converting the package into something that only works on their own distro.
> 
> I believe I can sum up my thoughts with: "Fuck that shit."

Generally I am of the opposite view, that using the distribution's package management is by far the best way (*). When a language decides it has to ignore platforms and provide it's own, I generally think "Another introverted, self obsessed language, ignoring platform's management structures."

Trying to cover every platform is though a real pain in the proverbials, I totally agree with that. But let's look at the need for coverage:

	Windows, OS X, Debian (hence Ubuntu, Mint), Fedora (hence RHEL, CentOS)

after that the user base is currently so low that people probably expect to fend for themselves.  Windows and OS X require handling because of the very nature of the infrastructure. Debian and Fedora need a good relationship with a recognized packager to get stuff into the distributions and repackaged for each version. This also goes for MacPorts, and Brew (I am guessing Fink is dying?).


(*) Debian has GCC and Python management taped nicely, multiple separate versions installable side-by-side and usable. On the other hand Debian totally sucks at handling anything related to Java because they insist on one and only one version of an artefact. It seems they believe the WORA fiction.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


February 18, 2013
On 2013-02-17 22:43, Dicebot wrote:

> What are the limitations then? I am only run-by Windows user, so it was
> actually a question.

As far as I'm aware it's only for applications. I hardly doubt you can but libraries and tools (command line) there. Same goes for the App Stor on Mac OS X.

-- 
/Jacob Carlborg
February 18, 2013
On 2013-02-18 00:51, David Nadlinger wrote:

> I think any D package management tool needs to be able to handle
> multiple coexisting compiler configurations, or at least allow being
> used for multiple installation (similar to RubyGems and rbenv/rvm).

Orbit and DVM :)

-- 
/Jacob Carlborg
February 18, 2013
Am 18.02.2013 00:51, schrieb David Nadlinger:
> On Sunday, 17 February 2013 at 14:40:26 UTC, Dicebot wrote:
>> Packaging is best done (and should be) by OS package manager, not hundreds of languages-specific managers. Good language package manager in my opinion is just an information source for OS package builders.
> 
> D does not lend itself well to OS-level packaging, because different compilers as well as different versions of the same compiler will not be binary-compatible in the foreseeable future.
> 
> I think any D package management tool needs to be able to handle multiple coexisting compiler configurations, or at least allow being used for multiple installation (similar to RubyGems and rbenv/rvm).
> 
> David
> 

On top of that, there are also certain use cases which usually are not possible using the typical OS package managers:

 - Install different versions of the same library for different
applications (in theory the right version schema would solve that, but
in practice this goes only for mature/stable libraries)

 - Installation by unprivileged users

 - Working on a library and a dependent application at the same time
(DUB supports "local" package sources for that) - normally this would
require to upload a new version of the library after each change and
then reinstall, or to completely leave the package system and manually
set different import paths for development

 - Automatic dependency installation not just for published packages,
but also for local/closed/WIP ones


Then there are also a lot of other D specific things to consider, such as compiler flags/version identifiers that may be defined in a single package, but need to be applied throughout all dependencies and the application itself to not get compiler/linker errors in the end.

But on the other hand, adding support for automatic OS package
generation may be a good option. All necessary information would be there.
February 18, 2013
On Mon, 18 Feb 2013 06:59:39 +0000
Russel Winder <russel@winder.org.uk> wrote:

> On Sun, 2013-02-17 at 16:32 -0500, Nick Sabalausky wrote: […]
> > I'm not real big on the idea of OS package managers. Not when Unix is in the picture anyway. I'm getting really fed up with software that has a "download / install" webpage populated with totally different instructions for an endless, yet always incomplete, list of Linux variants. And *maybe* BSD. And then on top of that, the poor *project* maintainers have to maintain all of that distro-specific cruft. Unless they're lucky and the project is big enough that the ditro maintainers are willing to waste *their* time converting the package into something that only works on their own distro.
> > 
> > I believe I can sum up my thoughts with: "Fuck that shit."
> 
> Generally I am of the opposite view, that using the distribution's package management is by far the best way (*). When a language decides it has to ignore platforms and provide it's own, I generally think "Another introverted, self obsessed language, ignoring platform's management structures."
> 
> Trying to cover every platform is though a real pain in the proverbials, I totally agree with that. But let's look at the need for coverage:
> 
> 	Windows, OS X, Debian (hence Ubuntu, Mint), Fedora (hence
> RHEL, CentOS)
> 
> after that the user base is currently so low that people probably expect to fend for themselves.  Windows and OS X require handling because of the very nature of the infrastructure. Debian and Fedora need a good relationship with a recognized packager to get stuff into the distributions and repackaged for each version. This also goes for MacPorts, and Brew (I am guessing Fink is dying?).
> 
> 
> (*) Debian has GCC and Python management taped nicely, multiple separate versions installable side-by-side and usable. On the other hand Debian totally sucks at handling anything related to Java because they insist on one and only one version of an artefact. It seems they believe the WORA fiction.
> 

I do like when I can just "apt-get install whatever" and be done. (Assuming I happen to know the package name used, and they're not always entirely intuitive). But then you always come across stuff that isn't in the repos or, almost as bad, needs requires jerking around with sources.list and then installing a key. May as well just download & unzip a file and be done with it (if linux actually had real binary compatibility).

But even that problem isn't because of anyone doing anything wrong, or app/lib developers failing to "see the light" of OS package managers. It's because of all the roadblocks in the way of making "proper" packages and getting them into the official repos. And keeping them properly up-to-date. And *those* roadblocks *aren't* the fault of the OS people or the OS package manager people. There isn't really anything they *can* do about it - it's all natural consequences of the whole OS-level package manager system. The fault lies with the model itself.

In other words, having OS package managers be the be-all-end-all of package management is a wonderful idea in theory, but it's a pie-in-the-sky dream. It's just not realisticlly feasable because the model just doesn't work well enough at scale:

Getting stuff into the right package formats, knowing how to even do that, getting it into the official repos, getting it *past* whatever testing/staging repos there may be, and then actually *to* people, and then getting updates promptly handled. And that's just public OSS stuff, there's a whole different set of issues for anything privately-distributed. It's all far too much to expect from the lib/app devs who already have more than enough to do.

So they don't do it. Why deal with all that red tape when you can just toss up a zip, while also giving your users the benefit of not having to wait for all those middlemen, or deal with a totally different set of install instructions for each system, or creating extra hurtles for less-major OSes, etc. It's a win-win devs and their users. So ultimately, OS-level package managers *encourage* developers not to use them. So yea, I like "apt-get install foobar" when it works, but it *can't* always work.

The whole thing is just a big broken dynamic that only works well for the big-name packages.