Re: stop to maitain rpm
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... :)
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
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
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
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
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
> 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
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
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
Re: stop to maitain rpm
On Mon, 2013-08-12 at 11:41 +0100, Iain Buclaw wrote: […] > > 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 — but that sort of makes sense really. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: stop to maitain rpm
On 12 August 2013 11:38, Russel Winder wrote: > On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote: > […] >> 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,…), Fedora (which gives RHEL, CentOS,… > ), MacPorts, HomeBrew, , 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 – but I may > 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) = (c & 0x0f) + '0';
Re: stop to maitain rpm
On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote: […] > 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,…), Fedora (which gives RHEL, CentOS,… ), MacPorts, HomeBrew, , 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 – 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? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: stop to maitain rpm
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
Re: stop to maitain rpm
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
Re: stop to maitain rpm
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.
Re: stop to maitain rpm
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
Re: stop to maitain rpm
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 :)
Re: stop to maitain rpm
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
