Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2020-04

Online Package Manager errors ?

26 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael Van Canneyt

Hi,

I tried to install a package using the package manager (Brook framework). The package manager tells me the compile failed.

How can I see what the actual error is ?

Or must I open the package manually, compile manually to see the error ?

If so, why isn't there a 'open this package' entry in the list of packages ?

I have no easy way of locating the package.
In the options, I found where the OLPM downloads the packages, but to get there on a mac involves an insane amount of clicking, provided I managed to remember the location where the package is supposed to be...

A browser's 'downloads' window allows you to open the file or open the file location. I think this could be a good addition to the OLPM.

Michael.

Reply by email

Balázs Székely
to Michael Van Canneyt

Hi Michael,

I tried to install a package using the package manager (Brook framework).

The package manager tells me the compile failed. How can I see what the actual error is ?

The Message Window is not obscured by OPM, usually I check the error messages there.
Ideally you shouldn't see any error messages :), however there are too many Lazarus/FPC version/widgetsets. I cannot check each package on every single platform. This should be the package maintainers job. In Lazarus trunk there is a small improvement though, if a package is not tested against a specific widgetset/Laz/FPC version, OPM will warn you, that the package compile might fail.

Or must I open the package manually, compile manually to see the error ?

If so, why isn't there a 'open this package' entry in the list of packages ?

This is a good idea, I can add an "open this package" entry.

have no easy way of locating the package.

Show quoted text 6 lines
In the options, I found where the OLPM downloads the packages, but to get there on a mac involves an insane amount of clicking, provided I managed to remember the location where the package is supposed to be...

Please click the "Local Repo" button(see attachment) , it will open a file manager window with the folder where the packages are installed.

regards,
Balázs.

On Mon, Apr 13, 2020 at 1:50 PM Michael Van Canneyt via lazarus <

Show quoted text 35 lines
wrote: Hi, I tried to install a package using the package manager (Brook framework). The package manager tells me the compile failed. How can I see what the actual error is ? Or must I open the package manually, compile manually to see the error ? If so, why isn't there a 'open this package' entry in the list of packages ? I have no easy way of locating the package. In the options, I found where the OLPM downloads the packages, but to get there on a mac involves an insane amount of clicking, provided I managed to remember the location where the package is supposed to be... A browser's 'downloads' window allows you to open the file or open the file location. I think this could be a good addition to the OLPM. Michael. -- _______________________________________________ lazarus mailing list https://lists.lazarus-ide.org/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/1844b875/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: OPM.png
Type: image/png
Size: 44323 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/1844b875/attachment-0001.png>

Reply by email

Michael Van Canneyt
to Balázs Székely
Balázs Székely wrote 8 lines
Hi Michael, I tried to install a package using the package manager (Brook framework). > The package manager tells me the compile failed. > How can I see what the actual error is ? > The Message Window is not obscured by OPM, usually I check the error messages there.

Duh ! I should have checked that...
The message window was obscured in my case.
Damn this docked IDE, I can't get used to it ;-)

Show quoted text 6 lines
Ideally you shouldn't see any error messages :), however there are too many Lazarus/FPC version/widgetsets. I cannot check each package on every single platform. This should be the package maintainers job. In Lazarus trunk there is a small improvement though, if a package is not tested against a specific widgetset/Laz/FPC version, OPM will warn you, that the package compile might fail.

OK, seems like a good idea.

BTW, the message was not meant to point out that there is a broken package. I understand perfectly you cannot check every possible package out there. I simply didn't see the messages window.

for completeness sake, here is the actual error:

brookfclfcgibroker.pas(23,12) Fatal: Cannot find CustFCGI used by BrookFCLFCGIBroker of package BrookRT.
Show quoted text 7 lines
Or must I open the package manually, compile manually to see the error ? > If so, why isn't there a 'open this package' entry in the list of packages > ? > This is a good idea, I can add an "open this package" entry.

Yes, please. That would be really handy ! See below.

Show quoted text 10 lines
have no easy way of locating the package. > In the options, I found where the OLPM downloads the packages, > but to get there on a mac involves an insane amount of clicking, > provided I managed to remember the location where the package is supposed > to > be... > Please click the "Local Repo" button(see attachment) , it will open a file manager window with the folder where the packages are installed.

Yes, I did that before mailing.

But when I open a package in this dialog, it shows me an empty file list :(

So, in order to open the package, I must then
* remember the location
* close this dialog and go to the 'open package file' dialog in the package menu.
* Browse to home directory.
* Enable showing hidden files with Cmd-Shift-Period to be able to select the .lazarus directory (this is Mac!)
* Continue to correct directory
* Open package file.
And then I see the correct file list in the package...

Now you will understand why I think the 'open this package' entry is a good idea ;-)

Thanks for looking at this :-)

Michael.

Reply by email

silvioprog
to Michael Van Canneyt: I tried to install a package using the package manager (Brook framework). The package…

Hi all.

On Mon, Apr 13, 2020 at 7:50 AM Michael Van Canneyt via lazarus <

Show quoted text 7 lines
wrote: Hi, I tried to install a package using the package manager (Brook framework). The package manager tells me the compile failed.

I took a look at the version available in OPM and noticed it provides the outdated version, available only for historical purposes.

New applications have to use Brook Tardigrade, available at risoflora/brookframework <https://github.com/risoflora/brookframework> (with a branch for minor changes: risoflora/brookframework/tree/v5.1 <https://github.com/risoflora/brookframework/tree/v5.1>). The OPM is supposed to provide it, named as "Brook Framework".

The old version is available at risoflora/brookfreepascal <https://github.com/risoflora/brookfreepascal>, however, it is not maintained so often.

cheers

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/9930cde1/attachment-0001.html>

Reply by email

Michael Van Canneyt
to silvioprog
silvioprog wrote 13 lines
Hi all. On Mon, Apr 13, 2020 at 7:50 AM Michael Van Canneyt via lazarus < > wrote: > Hi, > > I tried to install a package using the package manager (Brook framework). > The package manager tells me the compile failed. > I took a look at the version available in OPM and noticed it provides the outdated version, available only for historical purposes.

As you are the author, I think it is your responsability to update the package entry, no ?

Michael.

Reply by email

Balázs Székely
to Michael Van Canneyt

@Michael

I implemented the 'open package entry' feature in r.62959. If a package is available locally, you can open it by clicking the Open button or double click the selected package(screenshot1). More over if a package compile/install fails, OPM will offer you to open the package(screenshot2).

@silvioprog
I will update Brook framework soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/32dc6d32/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: OPM2.png
Type: image/png
Size: 26738 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/32dc6d32/attachment-0002.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: OPM1.png
Type: image/png
Size: 46538 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/32dc6d32/attachment-0003.png>

Reply by email

Michael Van Canneyt
to Balázs Székely
Balázs Székely wrote 6 lines
@Michael I implemented the 'open package entry' feature in r.62959. If a package is available locally, you can open it by clicking the Open button or double click the selected package(screenshot1). More over if a package compile/install fails, OPM will offer you to open the package(screenshot2).

Nice :-) Great job !

While we're at it: meanwhile I enabled the 'Package maintainer' profile. I get then the option to specify files/directories that should be excluded from zip files.

I see no need to make this 2 lists ?
.gitignore and friends also don't need 2 separate lists.

One list of names/masks should suffice, don't you think ? Or is there a reason for having the 2 lists separate ? (maybe I fail to see something)

Michael.

Reply by email

silvioprog
to Michael Van Canneyt: As you are the author, I think it is your responsability to update the package entry, no ?

On Mon, Apr 13, 2020 at 11:56 AM Michael Van Canneyt via lazarus <

wrote: As you are the author, I think it is your responsability to update the package entry, no ?

hm... I never published a package at OPM repository before, so I don't know how to do that (yet). 😅

In next message Balázs wrote he will update it soon, so I would appreciate to help him on that.

I have a naive suggestion for OPM. I'm going to talk about that a little in next message ...

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/75923403/attachment.html>

Reply by email

silvioprog
to Balázs Székely: @Michael I implemented the 'open package entry' feature in r.62959. If a package is…

On Mon, Apr 13, 2020 at 1:58 PM Balázs Székely via lazarus <

Show quoted text 5 lines
wrote: @silvioprog I will update Brook framework soon.

Thank you very much for maintaining OPM! And feel absolutely free to ask any question about the package if you need. 👍

I have a naive suggestion for OPM. Some components depends on external libraries/binaries (libffi, openssl, libsagui etc.), so it would be nice any field like "Libraries", or "Dependencies", or even "External files" inside the "Package info", providing previous information that the package needs external libraries/files to work properly. (sorry if it is already implemented, I'm using Lazarus 2.0.6)

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/d76f1af2/attachment.html>

Reply by email

Balázs Székely
to silvioprog

@Michael

Or is there a reason for having the 2 lists separate ?

Other then visually separate files from folders there is no reason.

One list of names/masks should suffice, don't you think ?

Yes I agree, it can be done with a single list. I add it to my "to do list" :)

@silvioprog
I updated Brook framework, by default win32/win64 and gtk2 are the supported widget sets. If your package works on other platform too, like: qt5, gtk3, cocoa, please let me know so I can update in OPM.

I have a naive suggestion for OPM. Some components depends on external

Show quoted text 6 lines
libraries/binaries (libffi, openssl, libsagui etc.), so it would be nice any field like "Libraries", or "Dependencies", or even "External files" inside the "Package info", providing previous information that the package needs external libraries/files to work properly. (sorry if it is already implemented, I'm using Lazarus 2.0.6)

Thanks for the suggestion. In my opinion the external libraries should be shipped with the package(if possible). Adding a new entry in the package tree it's not a problem, it can be done in 15-20 minutes, however the list already has a "Christmas tree" feeling to it. Any extra info should be added to the "package description" or "community description" entries, which can be opened in a separate form.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/cc4ca37b/attachment.html>

Reply by email

Sven Barth
to Balázs Székely

Balázs Székely via lazarus schrieb am Mo.,
13. Apr. 2020, 20:08:

Show quoted text 15 lines
I have a naive suggestion for OPM. Some components depends on external > libraries/binaries (libffi, openssl, libsagui etc.), so it would be nice > any field like "Libraries", or "Dependencies", or even "External files" > inside the "Package info", providing previous information that the package > needs external libraries/files to work properly. (sorry if it is already > implemented, I'm using Lazarus 2.0.6) > Thanks for the suggestion. In my opinion the external libraries should be shipped with the package(if possible). Adding a new entry in the package tree it's not a problem, it can be done in 15-20 minutes, however the list already has a "Christmas tree" feeling to it. Any extra info should be added to the "package description" or "community description" entries, which can be opened in a separate form.

I don't agree. Especially on Linux (and the BSDs probably as well) that is part of the OS' package manager, even for macOS there is an open source one that one can install to handle such things. So a list of required dependencies would be enough.

This list would also be useful for deployment of the final application however so that one can either set up an installer / package correctly or report to the user in a Readme or so what libraries are required.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/78ad7b87/attachment-0001.html>

Reply by email

silvioprog
to Balázs Székely: @Michael Other then visually separate files from folders there is no reason. One list of…

On Mon, Apr 13, 2020 at 3:08 PM Balázs Székely via lazarus <

Show quoted text 7 lines
wrote: @silvioprog I updated Brook framework, by default win32/win64 and gtk2 are the supported widget sets. If your package works on other platform too, like: qt5, gtk3, cocoa, please let me know so I can update in OPM.

Thanks for updating! However, I would like to do some changes in "Package info / Community description" info soon. Where can I change this?

Regarding qt/gtk/cocoa, the component doesn't depend on any widget.

I have a naive suggestion for OPM. Some components depends on external

Show quoted text 13 lines
> libraries/binaries (libffi, openssl, libsagui etc.), so it would be nice > any field like "Libraries", or "Dependencies", or even "External files" > inside the "Package info", providing previous information that the package > needs external libraries/files to work properly. (sorry if it is already > implemented, I'm using Lazarus 2.0.6) > Thanks for the suggestion. In my opinion the external libraries should be shipped with the package(if possible). Adding a new entry in the package tree it's not a problem, it can be done in 15-20 minutes, however the list already has a "Christmas tree" feeling to it. Any extra info should be added to the "package description" or "community description" entries, which can be opened in a separate form.

It is not often possible to distribute libraries due to license issues, so something clear alerting about required libraries would be great.

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200413/a4e20757/attachment.html>

Reply by email

Michael Van Canneyt
to Sven Barth: Balázs Székely via lazarus schrieb am Mo., 13. Apr. 2020, 20:08: I don't agree.…
Sven Barth wrote 27 lines
Balázs Székely via lazarus schrieb am Mo., 13. Apr. 2020, 20:08: > > I have a naive suggestion for OPM. Some components depends on external >> libraries/binaries (libffi, openssl, libsagui etc.), so it would be nice >> any field like "Libraries", or "Dependencies", or even "External files" >> inside the "Package info", providing previous information that the package >> needs external libraries/files to work properly. (sorry if it is already >> implemented, I'm using Lazarus 2.0.6) >> > Thanks for the suggestion. In my opinion the external libraries should be > shipped with the package(if possible). Adding a new entry in the package > tree it's not a problem, it can be done in 15-20 minutes, however the list > already has a "Christmas tree" feeling to it. Any extra info should be > added to the "package description" or "community description" entries, > which can be opened in a separate form. > I don't agree. Especially on Linux (and the BSDs probably as well) that is part of the OS' package manager, even for macOS there is an open source one that one can install to handle such things. So a list of required dependencies would be enough. This list would also be useful for deployment of the final application however so that one can either set up an installer / package correctly or report to the user in a Readme or so what libraries are required.

+1.

Don't distribute binaries, only sources. The binary may not work on all distributions, you'd need to provide one for all platforms (which you may not have yourself). It may be outdated, no security fixed applied etc..

Michael.

Reply by email

Balázs Székely
to Michael Van Canneyt

@Sven, @silvioprog, @Michael
OK. No binaries then. Obviously I'm a "windows minded" person, with little experience on other platforms.
As a side node, OPM filters out binaries by default, however for a few well known packages, dlls were allowed, which turned out great and was appreciated by users. Hence my (wrong) suggestion.

@silvioprog

Thanks for updating! However, I would like to do some changes in "Package info / Community description" info soon. Where can I change this?

You're welcome. Just tell me what to change and I will change it. Unfortunately there is no automatic mechanism for now(see my reply in the other thread).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/6032b4ce/attachment-0001.html>

Reply by email

Balázs Székely
to Balázs Székely

@silvioprog
I added the "external dependencies" node to OPM, so it can be used in the future.

AM Balázs Székely wrote 16 lines
@Sven, @silvioprog, @Michael OK. No binaries then. Obviously I'm a "windows minded" person, with little experience on other platforms. As a side node, OPM filters out binaries by default, however for a few well known packages, dlls were allowed, which turned out great and was appreciated by users. Hence my (wrong) suggestion. @silvioprog > Thanks for updating! However, I would like to do some changes in "Package > info / Community description" info soon. Where can I change this? > You're welcome. Just tell me what to change and I will change it. Unfortunately there is no automatic mechanism for now(see my reply in the other thread).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/bed14ddc/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: OPM.png
Type: image/png
Size: 47617 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/bed14ddc/attachment-0001.png>

Reply by email

silvioprog
to Michael Van Canneyt: +1. Don't distribute binaries, only sources. The binary may not work on all…

On Tue, Apr 14, 2020 at 12:23 AM Michael Van Canneyt via lazarus <

Show quoted text 6 lines
wrote: +1. Don't distribute binaries, only sources.

Please notice I'm not suggesting to distribute binaries, but only some field to indicate the package depends on external libraries/binaries, like other package managers and distribution methods does (appimage/.deb/.rpm/getit/npm/nuget/cmake and so on), i.e. make it easy to the programmer known about required dependencies.

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/8f8dc897/attachment.html>

Reply by email

silvioprog
to Balázs Székely: @Sven, @silvioprog, @Michael OK. No binaries then. Obviously I'm a "windows minded"…

On Tue, Apr 14, 2020 at 3:02 AM Balázs Székely via lazarus <

Show quoted text 6 lines
wrote: You're welcome. Just tell me what to change and I will change it. Unfortunately there is no automatic mechanism for now(see my reply in the other thread).

Thank you!

(is the created? :-) )

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/2df38ae4/attachment.html>

Reply by email

silvioprog
to Balázs Székely: @silvioprog I added the "external dependencies" node to OPM, so it can be used in the…

On Tue, Apr 14, 2020 at 4:18 AM Balázs Székely via lazarus <

Show quoted text 6 lines
wrote: @silvioprog I added the "external dependencies" node to OPM, so it can be used in the future.

Wow, it is exactly I'm looking for! Thank you more one time! 😀

I'm going to send the description and external dependencies I would like to add for the Brook package ... (should I send to ?)

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/70a7095e/attachment.html>

Reply by email

Balázs Székely
to silvioprog: On Tue, Apr 14, 2020 at 4:18 AM Balázs Székely via lazarus < Wow, it is exactly I'm…
(should I send to ?)

Yes please. I will update OPM as soon as possible.

On Tue, Apr 14, 2020 at 3:14 PM silvioprog via lazarus <

Show quoted text 23 lines
wrote: On Tue, Apr 14, 2020 at 4:18 AM Balázs Székely via lazarus < > wrote: > @silvioprog > I added the "external dependencies" node to OPM, so it can be used in > the future. > Wow, it is exactly I'm looking for! Thank you more one time! 😀 I'm going to send the description and external dependencies I would like to add for the Brook package ... (should I send to ?) -- Silvio Clécio -- _______________________________________________ lazarus mailing list https://lists.lazarus-ide.org/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/793b81dc/attachment-0001.html>

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt: +1. Don't distribute binaries, only sources. The binary may not work on all…

Hi,

Στις 14/4/2020 6:23 π.μ., ο Michael Van Canneyt via lazarus έγραψε:

Show quoted text 8 lines
On Tue, 14 Apr 2020, Sven Barth via lazarus wrote: > Balázs Székely via lazarus schrieb am > Mo., > 13. Apr. 2020, 20:08: >

< snip >

Show quoted text 28 lines
>> shipped with the package(if possible). Adding a new entry in the >> package >> tree it's not a problem, it can be done in 15-20 minutes, however >> the list >> already has a "Christmas tree" feeling to it. Any extra info should be >> added to the "package description"  or "community description" entries, >> which can be opened in a separate form. >> > > I don't agree. Especially on Linux (and the BSDs probably as well) > that is > part of the OS' package manager, even for macOS there is an open > source one > that one can install to handle such things. So a list of required > dependencies would be enough. > > This list would also be useful for deployment of the final application > however so that one can either set up an installer / package > correctly or > report to the user in a Readme or so what libraries are required. +1. Don't distribute binaries, only sources. The binary may not work on all distributions, you'd need to provide one for all platforms (which you may not have yourself). It may be outdated, no security fixed applied etc.. Michael.

Hmm, how about archive and/or object files for static linking ? An approach that I saw in mormot ( I don't know if it is the same in OPK I didn't check the package there ... )

In my case I'm writing a package that it'll use a specific version of
libusb, and I was thinking to use static linking to solve this  .

regads,

Dimitrios Chr. Ioannidis

Reply by email

silvioprog
to Dimitrios Chr. Ioannidis

On Tue, Apr 14, 2020 at 9:25 AM Dimitrios Chr. Ioannidis via lazarus <

Show quoted text 6 lines
wrote: Hmm, how about archive and/or object files for static linking ? An approach that I saw in mormot ( I don't know if it is the same in OPK I didn't check the package there ... )

IIRC mormot distributes its static libraries with its source code.

In my case I'm writing a package that it'll use a specific version of
Show quoted text 5 lines
libusb, and I was thinking to use static linking to solve this . regads, -- Dimitrios Chr. Ioannidis=

There is a promising PM called "PMake" I think you would like to know: https://github.com/daar/pmake . :-)

Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/c27cf449/attachment.html>

Reply by email

Dimitrios Chr. Ioannidis
to silvioprog

Hi,

Στις 14/4/2020 3:42 μ.μ., ο silvioprog via lazarus έγραψε:

Show quoted text 11 lines
On Tue, Apr 14, 2020 at 9:25 AM Dimitrios Chr. Ioannidis via lazarus < <mailto:>> wrote: Hmm, how about archive and/or object files for static linking ? An approach that I saw in mormot ( I don't know if it is the same in OPK I didn't check the package there ... ) IIRC mormot distributes its static libraries with its source code.

The mormot package in OPK distribute it's static libraries also ?  ( I'll have to look, but I'm sure that they do )

I asked because of the suggestion / rule to not distribute binary files via OPK.

regards,

Dimitrios Chr. Ioannidis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200414/99e9c4d1/attachment.html>

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis: Στις 14/4/2020 6:23 π.μ., ο Michael Van Canneyt via lazarus έγραψε: < snip >…
Dimitrios Chr. Ioannidis wrote 9 lines
> Don't distribute binaries, only sources. The binary may not work on all > distributions, you'd need to provide one for all platforms (which you may > not have yourself). It may be outdated, no security fixed applied etc.. > > Michael. Hmm, how about archive and/or object files for static linking ? An approach that I saw in mormot ( I don't know if it is the same in OPK I didn't check the package there ... )

Not good, you need to provide this for all possible architectures, and that's not possible for most people.

And I would say this is a big flaw in the way mormot operates.

Distributing binaries is simply a big no-no. You must rely on the package manager of your system for that.

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt

Hi,

Στις 14/4/2020 4:15 μ.μ., ο Michael Van Canneyt via lazarus έγραψε:

Show quoted text 18 lines
On Tue, 14 Apr 2020, Dimitrios Chr. Ioannidis wrote: >> Don't distribute binaries, only sources. The binary may not work on all >> distributions, you'd need to provide one for all platforms (which >> you may >> not have yourself). It may be outdated, no security fixed applied etc.. >> >> Michael. > > Hmm, how about archive and/or object files for static linking ? An > approach that I saw in mormot ( I don't know if it is the same in OPK > I didn't check the package there ... ) Not good, you need to provide this for all possible architectures, and that's not possible for most people.

Yeap, I understand this. I'm still thinking my options .

< snip >

Distributing binaries is simply a big no-no. You must rely on the package manager of your system for that.

You've got a point. After all, someone that uses a IDE and a compiler AND want to install some packages, I assume that is capable enough to use his system's package manager to solve any dependencies that may exist ...

But I'm not sure that I understand completely regarding what is allowed for getting a package accepted in OPK.

Is it a suggestion / best practice not to distribute binaries on OPK or is it an prerequisite for acceptance ?

Could anyone plz clarify ?

regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 33 lines
Hi, Στις 14/4/2020 4:15 μ.μ., ο Michael Van Canneyt via lazarus έγραψε: > > > On Tue, 14 Apr 2020, Dimitrios Chr. Ioannidis wrote: > >>> Don't distribute binaries, only sources. The binary may not work on all >>> distributions, you'd need to provide one for all platforms (which >>> you may >>> not have yourself). It may be outdated, no security fixed applied etc.. >>> >>> Michael. >> >> Hmm, how about archive and/or object files for static linking ? An >> approach that I saw in mormot ( I don't know if it is the same in OPK >> I didn't check the package there ... ) > > Not good, you need to provide this for all possible architectures, and > that's not > possible for most people. Yeap, I understand this. I'm still thinking my options . < snip > > Distributing binaries is simply a big no-no. You must rely on the package > manager of your system for that. You've got a point. After all, someone that uses a IDE and a compiler AND want to install some packages, I assume that is capable enough to use his system's package manager to solve any dependencies that may exist ...

Exactly my reasoning.

Michael.

Reply by email