www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dub and debian packaging

reply ikod <geller.garry gmail.com> writes:
Hello

I'd like to hear any opinions and best practices on coexistence 
of dub and debian .deb packaging and deployment.

Here is my problem: I wrote some small library that use Pegged to 
parse and process user requests. This library can be  used in 
shebang-scripts on servers or can be statically linked to 
applications. The first case require library code and 
dependencies (Pegged in this case) be deployed on servers to some 
well-known system-wide place like /usr/include/d/ so that any 

-I/usr/include/d` in his script.

And here is a problem: we (like many other) distribute our 
software over our debian-based machines using standard debian 
packaging system. There is no problem for me to wrap my library 
into .deb. The question about Pegged or any other dub-based D 
library - how do you think, what is better way to tie together 
dub and deb-packaged software?

Should I use some postinstall scripts to fetch-build-deploy 
Pegged to /usr/include/d/ using dub, or should I wrap Pegged in 
separate .deb and include it dependencies in my library or any 
other package relying on Pegged? For me the latter way is better/ 
but what is your opinion?
Jan 25 2016
next sibling parent reply Paul O'Neil <redballoon36 gmail.com> writes:
On 01/25/2016 12:08 PM, ikod wrote:

 Hello
 
 I'd like to hear any opinions and best practices on coexistence of dub
 and debian .deb packaging and deployment.
 
 Here is my problem: I wrote some small library that use Pegged to parse
 and process user requests. This library can be  used in shebang-scripts
 on servers or can be statically linked to applications. The first case
 require library code and dependencies (Pegged in this case) be deployed
 on servers to some well-known system-wide place like /usr/include/d/ so

 -I/usr/include/d` in his script.
 
 And here is a problem: we (like many other) distribute our software over
 our debian-based machines using standard debian packaging system. There
 is no problem for me to wrap my library into .deb. The question about
 Pegged or any other dub-based D library - how do you think, what is
 better way to tie together dub and deb-packaged software?
 
 Should I use some postinstall scripts to fetch-build-deploy Pegged to
 /usr/include/d/ using dub, or should I wrap Pegged in separate .deb and
 include it dependencies in my library or any other package relying on
 Pegged? For me the latter way is better/ but what is your opinion?
 
 


I think there's a longer discussion one one of the dub issues that
explains why this doesn't exist yet.  The blocker is that the D ABI is
not compatible across compilers (dmd vs. ldc vs. gdc) or compiler
versions (2.068 vs. 2.069).  Until there's a reasonable resolution to
that problem, I don't think there will be OS packages of libraries.

-- 
Paul O'Neil
Github / IRC: todayman
Jan 25 2016
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Monday, 25 January 2016 at 23:46:09 UTC, Paul O'Neil wrote:

 On 01/25/2016 12:08 PM, ikod wrote:

 Hello
 
 I'd like to hear any opinions and best practices on 
 coexistence of dub and debian .deb packaging and deployment.
 
 Here is my problem: I wrote some small library that use Pegged 
 to parse and process user requests. This library can be  used 
 in shebang-scripts on servers or can be statically linked to 
 applications. The first case require library code and 
 dependencies (Pegged in this case) be deployed on servers to 
 some well-known system-wide place like /usr/include/d/ so that 

 --shebang -I/usr/include/d` in his script.
 
 And here is a problem: we (like many other) distribute our 
 software over our debian-based machines using standard debian 
 packaging system. There is no problem for me to wrap my 
 library into .deb. The question about Pegged or any other 
 dub-based D library - how do you think, what is better way to 
 tie together dub and deb-packaged software?
 
 Should I use some postinstall scripts to fetch-build-deploy 
 Pegged to /usr/include/d/ using dub, or should I wrap Pegged 
 in separate .deb and include it dependencies in my library or 
 any other package relying on Pegged? For me the latter way is 
 better/ but what is your opinion?
 
 


 I think there's a longer discussion one one of the dub issues 
 that explains why this doesn't exist yet.  The blocker is that 
 the D ABI is not compatible across compilers (dmd vs. ldc vs. 
 gdc) or compiler versions (2.068 vs. 2.069).  Until there's a 
 reasonable resolution to that problem, I don't think there will 
 be OS packages of libraries.


Note that the OP is essentially talking about source distribution 
for use in rdmd scripts. So ABI is not an issue. This source 
could be installed as a Debian package, but since dub exists, the 
question is whether to use dub or not. If not, there'll be two 
parallel ways to install source. In any case, files should be 
written to system directories and it should be possible to 
uninstall.

The question originates from here: 
https://github.com/PhilippeSigaud/Pegged/issues/171
Jan 26 2016
parent ikod <geller.garry gmail.com> writes:
On Tuesday, 26 January 2016 at 11:06:40 UTC, Bastiaan Veelo wrote:

 On Monday, 25 January 2016 at 23:46:09 UTC, Paul O'Neil wrote:

 On 01/25/2016 12:08 PM, ikod wrote:

 [...]


 I think there's a longer discussion one one of the dub issues 
 that explains why this doesn't exist yet.  The blocker is that 
 the D ABI is not compatible across compilers (dmd vs. ldc vs. 
 gdc) or compiler versions (2.068 vs. 2.069).  Until there's a 
 reasonable resolution to that problem, I don't think there 
 will be OS packages of libraries.


 Note that the OP is essentially talking about source 
 distribution for use in rdmd scripts. So ABI is not an issue. 
 This source could be installed as a Debian package, but since 
 dub exists, the question is whether to use dub or not. If not, 
 there'll be two parallel ways to install source. In any case, 
 files should be written to system directories and it should be 
 possible to uninstall.


Yes, exactly. As mentioned before, binaries in D are mostly 
statically linked, and for statically linked binaries there is no 
problem with dependencies. When this change, then binary 
distribution will also requre packaged dependencies.


 The question originates from here: 
 https://github.com/PhilippeSigaud/Pegged/issues/171
Jan 26 2016
prev sibling parent Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-01-25 18:08 GMT+01:00 ikod via Digitalmars-d <
digitalmars-d puremagic.com>:


 Hello

 I'd like to hear any opinions and best practices on coexistence of dub and
 debian .deb packaging and deployment.

 Here is my problem: I wrote some small library that use Pegged to parse
 and process user requests. This library can be  used in shebang-scripts on
 servers or can be statically linked to applications. The first case require
 library code and dependencies (Pegged in this case) be deployed on servers
 to some well-known system-wide place like /usr/include/d/ so that any

 -I/usr/include/d` in his script.

 And here is a problem: we (like many other) distribute our software over
 our debian-based machines using standard debian packaging system. There is
 no problem for me to wrap my library into .deb. The question about Pegged
 or any other dub-based D library - how do you think, what is better way to
 tie together dub and deb-packaged software?

 Should I use some postinstall scripts to fetch-build-deploy Pegged to
 /usr/include/d/ using dub, or should I wrap Pegged in separate .deb and
 include it dependencies in my library or any other package relying on
 Pegged? For me the latter way is better/ but what is your opinion?


`dub` is primarily meant for development.
You most likely want to compile the binary, and distribute it this way.
There are some additional advantages, for example you don't have to care
about the compiler version installed on the server anymore (you don't need
any), and it is most likely to save ressources, as, AFAIK, Pegged is quite
template-heavy and if you go into complex expression DMD will just eat your
whole memory.
Jan 25 2016