www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - stop to maitain rpm

reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
Too many project is a nightmare to package.
Developper do not see that dub is a tool to help user to get some 
D lib as is done in ruby python or perl. But dub is not for 
packaging!

I am lazy to do this job and D packaging

good luck
Aug 11 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
Dear Jonathan,

It's sad to see you go, we desperately need any help we can get 
on the packaging front (for all those who don't know, Jonathan 
aka bioinfornatics has been maintaining several D-related 
packages in the official Fedora repositories).

However, I would argue that D libraries should not be packaged 
using the typical operating system package management facilities 
anyway, as those are very much tailored to mature C/C++ 
libraries. In the case of D, even if a given library tried to 
maintain a stable ABI, it would not succeed as the various 
compilers and different versions of the same compiler are not 
ABI-compatible (yet).

Together with the fact that one often wants to use several D 
compilers side by side (e.g. DMD for quick debug builds, LDC for 
optimized release versions, or the latest DMD version for a new 
project along with a slightly older one for some code that has 
not been updated yet), I think that dedicated language-specific 
tools like they are common with other newer programming languages 
are also the way to go for D.

What would be nice, however, is to have these D-specific tools 
such as DVM, dub, … available in the distro repositories, 
preconfigured to fit the customs of the given system. This way, 
users could just do "yum install dvm dub" (or whatever other 
tools) to get a fully working D environment.

David
Aug 11 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 11 August 2013 at 17:15:52 UTC, David Nadlinger wrote:

 What would be nice, however, is to have these D-specific tools
 such as DVM, dub, … available in the distro repositories


Work in progress :)
Aug 11 2013
prev sibling parent reply "Moritz Maxeiner" <moritz ucworks.org> writes:
On Sunday, 11 August 2013 at 17:15:52 UTC, David Nadlinger wrote:

 What would be nice, however, is to have these D-specific tools 
 such as DVM, dub, … available in the distro repositories, 
 preconfigured to fit the customs of the given system. This way, 
 users could just do "yum install dvm dub" (or whatever other 
 tools) to get a fully working D environment.


I don't know how it is for other distros, but the newest dmd and 
ldc version are available in the Archlinux's [community] 
repository while gdc and dub are available in the AUR, meaning 
you get a fully working D environment on Archlinux by doing
yaourt -S dmd dub
or
yaourt -S gdc dub
or
yaourt -S ldc dub
(you could use any pacman-wrapper other than yaourt, as well of 
course)

So far there isn't a dvm package (for Arch) that I can see, but 
if anyone where really interested he could do so, as the AUR 
anyone who registers an account may create (and maintain) new 
packages.


- Moritz
Aug 12 2013
parent reply David <d dav1d.de> writes:
 I don't know how it is for other distros, but the newest dmd and ldc
 version are available in the Archlinux's [community] repository while
 gdc and dub are available in the AUR, meaning you get a fully working D
 environment on Archlinux by doing


LDC is in [community] already, and iirc Dicebot is working on getting
GDC into [community], too
Aug 12 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 12 August 2013 at 13:46:52 UTC, David wrote:

 LDC is in [community] already, and iirc Dicebot is working on 
 getting
 GDC into [community], too


Actually I am simply waiting until my PGP key gets signed by at 
least 3 Arch Linux master keys :) Will make announcement about 
all package changes and yummies once done.
Aug 12 2013
prev sibling parent "Moritz Maxeiner" <moritz ucworks.org> writes:
On Monday, 12 August 2013 at 13:46:52 UTC, David wrote:

 I don't know how it is for other distros, but the newest dmd 
 and ldc
 version are available in the Archlinux's [community] 
 repository while
 gdc and dub are available in the AUR, meaning you get a fully 
 working D
 environment on Archlinux by doing


 LDC is in [community] already


Um, that is what I wrote, isn't it?

, and iirc Dicebot is working on

 getting
 GDC into [community], too


Yes, I currently maintain the gdc-git package in AUR and he 
contacted me about getting it into [community]. But since gdc-git 
is a development package based on gcc 4.9 instead of gcc 4.8 
(like current Arch [core] gcc), I made a seperate package "gdc" 
(also available in the AUR atm) for that purpose. I believe that 
when he's done with the PGP key issue and has looked the PGKBUILD 
for the "gdc" package over he'll adopt the "gdc" package into 
[community], at which point it'll be removed from the AUR.
Aug 13 2013
prev sibling next sibling parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
I had release all rpm 
https://lists.fedoraproject.org/pipermail/devel/2013-August/187609.html

if no one take it they will go out of fedora.

I am lazy to explain that is not :
- a build system or dub
but
- a build system and dub

Firstly not everyone spent time to search their tool from cpan 
rvm pypi …
Secondly when you want the lib A who need bib B who need … you 
appreciate to have it in your repo
Third FHS rules and other was no create to annoyed dev…

If D dev should to install a compiller next a lib A dev a little 
get another lib … that is easier when that is into repo . That 
help to brings new users when all is into a repo

I had plan to package dub and vibe.d soon but now i stop all.

In brief That is a build system and dub
Aug 12 2013
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Monday, 12 August 2013 at 07:13:11 UTC, bioinfornatics wrote:

 I had release all rpm 
 https://lists.fedoraproject.org/pipermail/devel/2013-August/187609.html

 if no one take it they will go out of fedora.

 I am lazy to explain that is not :
 - a build system or dub
 but
 - a build system and dub

 Firstly not everyone spent time to search their tool from cpan 
 rvm pypi …
 Secondly when you want the lib A who need bib B who need … you 
 appreciate to have it in your repo
 Third FHS rules and other was no create to annoyed dev…

 If D dev should to install a compiller next a lib A dev a 
 little get another lib … that is easier when that is into repo 
 . That help to brings new users when all is into a repo


dub suits this purpose just fine. It's a build tool and a package 
manager. It can be used just like the various Linux package 
managers (dub install libname), but but it's even better in that 
you can skip that step entirely. List your project's dependencies 
in a package.json, and dub will automatically download and 
install them. Then they become available for every project you 
build with dub.

As a library maintainer, I find this much cleaner than relying on 
different people to maintain packages for different package 
managers. dubs configuration integrates with my git repo. The 
responsibility for registering with the dub registry is on me and 
I can keep it up to date with a simple config file. Most 
importantly, it makes it more likely that more users are on the 
same version and they can easily get the latest bug fixes when I 
update git without any extra effort on my part. On every platform 
that dub supports, not just Linuxen. rpms, deb files and whatnot 
often fall behind in the official package repositories and each 
one is only available to a certain subset of Linux users. dub is 
just a better option all around.
Aug 12 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote:
[=E2=80=A6]

 dub suits this purpose just fine. It's a build tool and a package=20
 manager. It can be used just like the various Linux package=20
 managers (dub install libname), but but it's even better in that=20
 you can skip that step entirely. List your project's dependencies=20
 in a package.json, and dub will automatically download and=20
 install them. Then they become available for every project you=20
 build with dub.
=20
 As a library maintainer, I find this much cleaner than relying on=20
 different people to maintain packages for different package=20
 managers. dubs configuration integrates with my git repo. The=20
 responsibility for registering with the dub registry is on me and=20
 I can keep it up to date with a simple config file. Most=20
 importantly, it makes it more likely that more users are on the=20
 same version and they can easily get the latest bug fixes when I=20
 update git without any extra effort on my part. On every platform=20
 that dub supports, not just Linuxen. rpms, deb files and whatnot=20
 often fall behind in the official package repositories and each=20
 one is only available to a certain subset of Linux users. dub is=20
 just a better option all around.


Anecdotal experience indicates this musn't be an "or" situation.

=46rom the Go experience, where this is furthest down the line in the
native code arena (as far as I know): for Go having *both* operating
system packaging *and* language specific packaging is the place to be.=20

The same goes for Python as well. Having platform packaging, and
individual machine packaging is wonderful.

Platform packaging gives automated update, local packaging give the
ability to get closer to the bleeding edge or stay behind the current
platform packaging.

So I think D (dmd, gdc, ldc) and Phobos (for each of dmd, gdc and ldc),
as well as any other D infrastructure packages  need to be packaged for
Debian (which gives Ubuntu, Mint,=E2=80=A6), Fedora (which gives RHEL, Cent=
OS,=E2=80=A6
), MacPorts, HomeBrew, <any-others-as-well>, and there needs to be a
(possibly dub-based) way of having a personal local installation of
things.

Currently GDC is in Debian, but I have to get DMD from a private Debian
repository instead of the official one, and I build LDC myself because
the Debian package is too old. This measn having to have three versions
of all the libraries and packages because each compiler requires it's
own. This sort of situation is well supported via platform packaging and
currently seems unsupported completely via D-specific things =E2=80=93 but =
I may
be missing something.

Surely the issue that is arising here is that there isn't much
communication and mutual support from the D community to the platform
packaging ones for the various platforms. (Apart from GDC on Debian,
which seems to be working fine now.)

So shouldn't OPs email be a call to get D and it's packages front and
centre for all package-based platforms *as well as* getting a D-specific
packaging system that knows how to deal with GitHub, BitBucket and
Launchpad (plus others) in place and core to the community. Go's set up
works, where is D's?


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Aug 12 2013
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Monday, 12 August 2013 at 10:38:21 UTC, Russel Winder wrote:


 Anecdotal experience indicates this musn't be an "or" situation.


Perhaps. My response in this thread derived from a brief exchange 
Jonathan and I had over at github. In packaging Derelict for 
Fedora, he had been relying on a pull request I accepted from him 
some time ago that added shared library support to the Derelict 
build script. I decided to remove it as it has fallen out of sync 
with the static builds now and again and it was only there for 
his use. At any rate, as part of my plans to restructure the 
project, I'm going to drop the build script and rely on dub 
exclusively. From his post here coming so soon after our 
exchange, I get the impression that I may not be the only one 
he's heard that from.

As long as packaging the various distros doesn't require any 
constraints on how I manage my projects, then it doesn't matter 
too much to me where or how people package it up. However, I do 
see benefits to promoting dub as the means to build up the D 
ecosystem. Then it's a central, goto location for D libraries and 
everybody's on the same page. As long as dmd/gdc/ldc and dub are 
available via the distro packages, that's all that really matters
Aug 12 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 12 August 2013 at 13:06:46 UTC, Mike Parker wrote:

 As long as packaging the various distros doesn't require any 
 constraints on how I manage my projects, then it doesn't matter 
 too much to me where or how people package it up. However, I do 
 see benefits to promoting dub as the means to build up the D 
 ecosystem. Then it's a central, goto location for D libraries 
 and everybody's on the same page. As long as dmd/gdc/ldc and 
 dub are available via the distro packages, that's all that 
 really matters


 From the point of view of packager I'd say there are 2 key issues 
here:

1) Developers tend to forget that tools like `dub` are for taking 
care of dependencies during development and end users won't have 
`dub`. Even if it is a library, dynamic linking implies that it 
will be pulled as a dependency not only by developers. That may 
result in complications for integrating package into existing 
package system. Sometimes.

2) `dub` is still quite immature when it comes to target path 
configuration (unless I have missed some changes) - converting 
its build output to FHS is not always convenient.

In my opinion, though, those are mostly quality of implementation 
issues, nothing fundamental. Can't say how much troubles does 
this really cause right now, have not tried to package anything 
like Derelict yet.
Aug 12 2013
parent reply "Mike Parker" <aldacron gmail.com> writes:
On Monday, 12 August 2013 at 13:38:11 UTC, Dicebot wrote:


 1) Developers tend to forget that tools like `dub` are for 
 taking care of dependencies during development and end users 
 won't have `dub`. Even if it is a library, dynamic linking 
 implies that it will be pulled as a dependency not only by 
 developers. That may result in complications for integrating 
 package into existing package system. Sometimes.


That's true. But, correct me if I'm wrong, rpms and the like are 
bundled independently of the original source repository. So a 
project relying solely on dub doesn't stop a package maintainer 
from keeping a separate build script to bundle with the rpm.
Aug 12 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 12 August 2013 at 14:34:04 UTC, Mike Parker wrote:

 That's true. But, correct me if I'm wrong, rpms and the like 
 are bundled independently of the original source repository. So 
 a project relying solely on dub doesn't stop a package 
 maintainer from keeping a separate build script to bundle with 
 the rpm.


Yeah, but imagine creating hard dependency on certain library 
version in sources (with no real need, something like too 
specific SONAME) - it requires package maintainer not only to 
keep bundling script, but also to patch project sources before 
building. Something maintainers are usually not happy to do :)

It is not that common but forgetting that user environment will 
be different from yours is kind of easier with all the 
convenience `dub` brings you.

In general I think keeping packager and developer duties separate 
is a good/right thing, however, it is much easier when developers 
think about binary dependencies separately from source ones.
Aug 12 2013
parent reply "Mike Parker" <aldacron gmail.com> writes:
On Monday, 12 August 2013 at 15:39:59 UTC, Dicebot wrote:

 On Monday, 12 August 2013 at 14:34:04 UTC, Mike Parker wrote:

 That's true. But, correct me if I'm wrong, rpms and the like 
 are bundled independently of the original source repository. 
 So a project relying solely on dub doesn't stop a package 
 maintainer from keeping a separate build script to bundle with 
 the rpm.


 Yeah, but imagine creating hard dependency on certain library 
 version in sources (with no real need, something like too 
 specific SONAME) - it requires package maintainer not only to 
 keep bundling script, but also to patch project sources before 
 building. Something maintainers are usually not happy to do :)

 It is not that common but forgetting that user environment will 
 be different from yours is kind of easier with all the 
 convenience `dub` brings you.

 In general I think keeping packager and developer duties 
 separate is a good/right thing, however, it is much easier when 
 developers think about binary dependencies separately from 
 source ones.


My view may indeed be heavily tinted by Windows, where this sort 
of thing just isn't an issue to care about. I suppose I'll have 
to adjust that a bit.
Aug 12 2013
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 12 August 2013 at 15:55:10 UTC, Mike Parker wrote:

 My view may indeed be heavily tinted by Windows, where this 
 sort of thing just isn't an issue to care about. I suppose I'll 
 have to adjust that a bit.


Hah, yeah, I guess the very understanding of user-distributed 
"package" is very different between various OS users. As far as I 
remember, it was considered a normal practice to pack all used 
shared libraries with programs installation in Windows (ignoring 
"shared" part) - something that is allowed in Linux repository 
packages only in absolutely exceptional cases. And Mac OS is 
somewhere in between.
Aug 12 2013
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 12 August 2013 at 13:06:46 UTC, Mike Parker wrote:

 In packaging Derelict for Fedora, he had been relying on a pull 
 request I accepted from him some time ago that added shared 
 library support to the Derelict build script.


Jonathan unfortunately has also opted to build druntime and 
Phobos as shared libraries in the LDC Fedora package, even if 
that is known to produce random segfaults due to the interaction 
with TLS not being properly handled yet (stay tuned for an new 
release early September including 2.063 and hopefully proper .so 
support on Linux). This might effectively be worse than having no 
D compiler package in the official repositories at all, as it is 
prone to give a false impression regarding the stability of D.

In part, this might have been partly our (or more specifically, 
my) fault for not clearly labeling the respective experimental 
CMake option as such and not explicitly pointing out the fact 
that shared libraries don't work out of the box without special 
hacks when asked about the possibility. And if I remember 
correctly, the Fedora packaging guidelines also pretty much 
prohibit distributing static libraries if it can be avoided at 
all (D is such a case, though, or has at least been until very 
recently).

In general, I think this situation highlights how important close 
collaboration and proper communication between upstream 
developers and packagers is. Sure, one could argue that the main 
project developers should also try to handle packaging for the 
most common target platforms, as it is also essential if the 
application is supposed to ever gain traction on systems where a 
package manager is used pervasively. However, in reality, we are 
all doing this in our spare time, and even if you restrict 
yourself to, say, Debian, Fedora, MacPorts and Homebrew, this 
probably means that you have to familiarize yourself with at 
least 3 systems you don't use on a daily basis before you can 
even think about creating packages for them.

Maintaining packages for your favorite system is a 
low-effort/high-impact way to help with D development; I really 
wish more users would consider lending a hand here.

David
Aug 12 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-12 12:38, Russel Winder wrote:


 Currently GDC is in Debian, but I have to get DMD from a private Debian
 repository instead of the official one, and I build LDC myself because
 the Debian package is too old. This measn having to have three versions
 of all the libraries and packages because each compiler requires it's
 own. This sort of situation is well supported via platform packaging and
 currently seems unsupported completely via D-specific things – but I may
 be missing something.


DVM installs each compiler in its own directory. Although you have to 
manually put libraries and imports in the correct directories. It also 
currently only supports DMD.

-- 
/Jacob Carlborg
Aug 12 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 12 August 2013 11:38, Russel Winder <russel winder.org.uk> wrote:

 On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote:
 [=85]

 dub suits this purpose just fine. It's a build tool and a package
 manager. It can be used just like the various Linux package
 managers (dub install libname), but but it's even better in that
 you can skip that step entirely. List your project's dependencies
 in a package.json, and dub will automatically download and
 install them. Then they become available for every project you
 build with dub.

 As a library maintainer, I find this much cleaner than relying on
 different people to maintain packages for different package
 managers. dubs configuration integrates with my git repo. The
 responsibility for registering with the dub registry is on me and
 I can keep it up to date with a simple config file. Most
 importantly, it makes it more likely that more users are on the
 same version and they can easily get the latest bug fixes when I
 update git without any extra effort on my part. On every platform
 that dub supports, not just Linuxen. rpms, deb files and whatnot
 often fall behind in the official package repositories and each
 one is only available to a certain subset of Linux users. dub is
 just a better option all around.


 Anecdotal experience indicates this musn't be an "or" situation.

 From the Go experience, where this is furthest down the line in the
 native code arena (as far as I know): for Go having *both* operating
 system packaging *and* language specific packaging is the place to be.

 The same goes for Python as well. Having platform packaging, and
 individual machine packaging is wonderful.

 Platform packaging gives automated update, local packaging give the
 ability to get closer to the bleeding edge or stay behind the current
 platform packaging.

 So I think D (dmd, gdc, ldc) and Phobos (for each of dmd, gdc and ldc),
 as well as any other D infrastructure packages  need to be packaged for
 Debian (which gives Ubuntu, Mint,=85), Fedora (which gives RHEL, CentOS,=


=85

 ), MacPorts, HomeBrew, <any-others-as-well>, and there needs to be a
 (possibly dub-based) way of having a personal local installation of
 things.

 Currently GDC is in Debian, but I have to get DMD from a private Debian
 repository instead of the official one, and I build LDC myself because
 the Debian package is too old. This measn having to have three versions
 of all the libraries and packages because each compiler requires it's
 own. This sort of situation is well supported via platform packaging and
 currently seems unsupported completely via D-specific things =96 but I ma=


y

 be missing something.


You can now get GDC from debian unstable if you want to risk it for a
biscuit.  Not recommended for Debian stable, and look up apt-pinning
for Debian testing releases.

Regards

Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Aug 12 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-08-12 at 11:41 +0100, Iain Buclaw wrote:
[=E2=80=A6]

=20
 You can now get GDC from debian unstable if you want to risk it for a
 biscuit.  Not recommended for Debian stable, and look up apt-pinning
 for Debian testing releases.


I am already on Debian Unstable with GDC 4.8.1-8 :-)

I am though tending to favour LDC at the moment since I am building
master/HEAD as the repository changes.

It seems that you have to work with one and only one D compiler =E2=80=94 b=
ut
that sort of makes sense really.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Aug 12 2013
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Mon, 12 Aug 2013 09:13:10 +0200, bioinfornatics wrote:


 I had release all rpm
 https://lists.fedoraproject.org/pipermail/devel/2013-August/187609.html
 
 if no one take it they will go out of fedora.
 
 I am lazy to explain that is not :
 - a build system or dub but - a build system and dub
 
 Firstly not everyone spent time to search their tool from cpan rvm pypi
 …
 Secondly when you want the lib A who need bib B who need … you
 appreciate to have it in your repo Third FHS rules and other was no
 create to annoyed dev…
 
 If D dev should to install a compiller next a lib A dev a little get
 another lib … that is easier when that is into repo . That help to
 brings new users when all is into a repo
 
 I had plan to package dub and vibe.d soon but now i stop all.
 
 In brief That is a build system and dub


I am willing to maintain those packages. Tell me what I have to do. I 
think I have Fedora account somewhere... :)
Oct 05 2013
prev sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
On 11/08/13 16:51, bioinfornatics wrote:

 Too many project is a nightmare to package.
 Developper do not see that dub is a tool to help user to get some D lib as is
done in ruby python or perl. But dub is not for packaging!
 
 I am lazy to do this job and D packaging
 


It's very sad hear that you leaves this great work. I'd like to hear you have
changed your decision. Let me ask you if your motives are only the exposed up
or there are another ones?

Regards,
-- 
Jordi Sayol
Aug 12 2013