View mode: basic / threaded / horizontal-split · Log in · Help
February 17, 2013
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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.
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home