dub: should we make it the de jure package manager for D?

[Jacob Carlborg]

On 2013-09-26 13:39, Dicebot wrote:

> No, you just let maintainers interested in target systems to take care
> of it. And package for 2-3 you care about _personally_. It is an
> obsolete idea that developer of a library/program should do any
> packaging at all. If your program is any good, there will always be
> volunteers to adapt it nicely for their beloved systems.

Most developers/packagers/people don't even know about D. They know even 
less about my projects. Be realistic.

> Yeah and what you propose is like mandatory requirement to have a
> separate home for every single electronics vendor. Want to buy something
> from different one? You must buy new home for it, period. (Well, feels
> like we are actually going there in real like >_<)

I'm just being realistic. Most of these packages won't ever end up in a 
system package manager.

>> It's the same with dub. I install a package to use the tool. But wait,
>> it actually _don't_, it just clones the repository. I have to figure
>> out myself how to compile and install the tool. It's only half way there.
>
> This is just plain wrong. dub takes care of proper compilation of any
> tool that is contained in its registry, you don't need to do anything
> about it.

It does _not_ compile packages using "dub install". At least not the one 
I created. Yes, it could compile it without any problem. It just doesn't 
do that when you run "dub install".

> But there is no possible legitimate reasons to install it.
> During development you can pretty much run in locally from the source
> dir. For end user distribution you must go system-specific way.



> It is neither a build tool nor package manager. It is a tool that
> aggregates different possible build tools backends and takes care of
> resolving build dependencies for them. Nothing more, nothing less.

It advertise itself as a package manager.

-- 
/Jacob Carlborg