On 21/11/2013 18:58, Dicebot wrote:
On Thu, 21 Nov 2013 13:11:27 +0000, Bruno Medeiros wrote:
These solutions involving dub using external/system package managers
don't feel right at all... I think this is a wrong approach.It is only possible correct approach for external/system dependencies that does not introduce own duplicate ecosystem.
Disk space is incredibly cheap. I don't mind duplicated files.
As for duplication of effort (maintenance effort etc.), yes there is
some extra effort involved, but I think it's worthwhile to pay that, in
order to have 100% cross-platform support.
Here's the idea:
The dub-package wrapper would include the library binaries (for all
available platforms)I will throw it away from Arch repos the very moment it will happen. Not really threatening but should show how serious am I about it.
What would you throw away from Arch repos? I'm not sure I'm
understanding you correctly. In this approach, the wrapper is a
dub-package, and therefore would live in the Dub registry (plus some git
repo for the actual contents), not in the Arch Linux repo.
Really, just pick some random free package manager implementation for Windows / Mac and push it as default for that platform. It will do much more good in long term.
"just pick some random free package manager implementation for Windows /
Mac" ??
Are you not thinking you are massively understimating the complexity of
the problem? Even if there was lots of manpower to develop this approach
in Dub, it is still a brittle mechanism. What about incompatibilities in
design between the various package managers? (I would bet there would be
lots of issues like that) What about incompatibilities between the
packages in the various PMs, relating to the same library. Issues, like,
one version is present in one PM, but not the other, or the version is
incorrectly specified in one PM but not the other, or even the package
is not present at all in one or some of the PMs... How can these issues
be adequately addressed if there is not one single entity per library
responsible for maitaining the various package formats of that library.
The only way to fully address this problem, taking care of both of our
concerns, would be to develop our own cross-platform system package
manager (or extend an existing one). But that is a massive undertaking.