Re: Ada package registry?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2016-01-31 16:52, Mart van de Wege wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On 2016-01-30 23:14, Tero Koskinen wrote:
>>
>>> Usually the repositories are maintained in "wiki"-style and anyone can
>>> update the package details (within certain limits). This causes some
>>> security concerns/implications, but in general there is not that much
>>> abuse and the repositories work well enough.
>>>
>>> The package repository management tool is used like this:
>>>
>>>    $ language_package_mananager install X
>>>    Downloading dependencies for 'X', please wait a while...
>>>    Downloading X...
>>>    Package 'X' installed!
>>>    $
>>
>> Yes, the problem is to have it working.
>>
>>> Once the package (a library usually) is installed (to your home
>>> directory), you can link it to your program and simply use it.
>>
>> No, that the point. It cannot be installed in your home directory. It
>> must be in the directories mandated by the target system
>> policy. E.g. for Debian Linux:
>>
>> https://people.debian.org/~lbrenta/debian-ada-policy.html#Files-provided-by-the-_002ddev-package
>>
> Nope.

There is no use in a repository that does not follow the target platform 
policy.

> Managing ADA_INCLUDE_PATH in an Ada equivalent would not be much
> different.

ADA_INCLUDE_PATH is not enough and of no use anyway because there is no 
way to control it.

I wrote a small tool to install pure Ada libraries:

http://www.dmitry-kazakov.de/ada/gps_installer.htm

But I would not consider this or similar as a solution, even approximately.

> This is not unique to Ada. Perl also has packages that require non-Perl
> libraries to be available, like XML::LibXML and Text::CSV::XS. The first
> has a dependency on libxml2, the second brings its own C code that must
> be compiled and then accessed from the Perl module.
>
> In both cases a hard build dependency on a working gcc environment
> exists; it is the end-user's responsibility to make sure it does exist
> and that the proper header files for the dependencies are installed.

If that can be user responsibility then everything else can be as well.

> Really, this is not a new issue. It is solvable, if you let go of the
> NIH mentality.

I would be glad to see a workable solution. The one where everything 
beyond trivial is user responsibility is already there.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de