September 27, 2012
On 27 September 2012 11:02, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 26/09/12 17:46, David Nadlinger wrote:
>>
>> Joseph, Russel, you seem to be both personally interested in D/LDC and
>> quite
>> knowledgeable about Debian-style packaging. Might I suggest that you think
>> about
>> joining the LDC forces as a package maintainer? It certainly isn't a huge
>> amount
>> of work to do, but many small items also add up…
>
>
> I'd love to, but it would be irresponsible to commit to it as (right now especially) I don't have a very good idea of what time I'll be able to offer.
>
> I also managed to royally screw up when going through beginners' packaging instructions for Ubuntu, so I'm not sure I'm the best choice here ... :-\


I'd advise to retrieve the LLVM source package and tailor for LDC instead rather than building from scratch.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
September 27, 2012
On 27/09/12 12:11, Iain Buclaw wrote:
>> I also managed to royally screw up when going through beginners' packaging
>> instructions for Ubuntu, so I'm not sure I'm the best choice here ... :-\
>
> I'd advise to retrieve the LLVM source package and tailor for LDC
> instead rather than building from scratch.

I wasn't even trying to build LDC at the time, just going through some "new to packaging" instructions on Launchpad.

BTW when you say "Tailor for LDC" what do you mean?  Isn't the LDC package meant to build against the target system LLVM?

September 27, 2012
On 27 September 2012 11:27, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 27/09/12 12:11, Iain Buclaw wrote:
>>>
>>> I also managed to royally screw up when going through beginners'
>>> packaging
>>> instructions for Ubuntu, so I'm not sure I'm the best choice here ... :-\
>>
>>
>> I'd advise to retrieve the LLVM source package and tailor for LDC instead rather than building from scratch.
>
>
> I wasn't even trying to build LDC at the time, just going through some "new to packaging" instructions on Launchpad.
>
> BTW when you say "Tailor for LDC" what do you mean?  Isn't the LDC package meant to build against the target system LLVM?
>

I meant clang. :-)

The source package for clang has mostly everything set-up for you. Source deps, Binary deps, etc.  I'd imagine the build process would be similar, just a case of replacing the clang sources with ldc, and tweaking the rules file to pick up ldc-specific installed files to package.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
September 27, 2012
On Thursday, 27 September 2012 at 10:43:08 UTC, Iain Buclaw wrote:
> I meant clang. :-)

Clang is an entirely different story, because it is built as part of the LLVM source tree/build process, checked out into llvm/tools/clang (at least usually, don't know if it's possible to build it separately)…

David
September 27, 2012
On 27/09/12 12:43, Iain Buclaw wrote:
> The source package for clang has mostly everything set-up for you.
> Source deps, Binary deps, etc.  I'd imagine the build process would be
> similar, just a case of replacing the clang sources with ldc, and
> tweaking the rules file to pick up ldc-specific installed files to
> package.

On a related note ... can we expect to see an updated GDC package in Quantal?
September 27, 2012
On Thu, Sep 27, 2012 at 11:46:12AM +0200, Joseph Rushton Wakeling wrote:
> On 27/09/12 09:20, Brad Roberts wrote:
> >On reflection, #4 is not going to work for dmd.. neither ubuntu nor debian, nor most distributions are going to be happy with the license situation.
> 
> Would Debian have a problem with a dmd package in non-free?
[...]

You'd have to ask the debian-legal mailing list for the official decision. But just to note, non-free is officially *not* a part of Debian, so it can contain anything that can be legally redistributed.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
September 27, 2012
On Thursday, 27 September 2012 at 02:07:32 UTC, Brad Roberts wrote:
> That works well for packages which are single source tree.  The current
> dmd, druntime, phobos, d-programming-language, tools separation makes that
> a little more challenging to put together, but not a lot.  It's probably
> worth doing regardless.  I realize that gdc and ldc are both in better
> shape in this area already.

Yep, for LDC "cmake . && make install" should be enough to build and install a working D2 compiler, including druntime and Phobos.

David
September 27, 2012
On Wed, Sep 26, 2012 at 07:14:12PM -0700, Brad Roberts wrote:
> On Wed, 26 Sep 2012, H. S. Teoh wrote:
> 
> > On Wed, Sep 26, 2012 at 05:58:08PM -0700, Brad Roberts wrote: [...]
> > > I don't know what's involved in getting built-packages into the various distributions.  I suspect that a number of them prefer to be built by their own automation from original (or forked) sources.  I'd be happy to engage with the appropriate people to explore ways to work together in this space.
> > [...]
> > 
> > For Debian, the process is relatively simple:
> > 
> > 1) Create a debian/ subdir in the source tree, with appropriate
> >    control files (for existing packages, this has already been done)
> >    a) Update debian/changelog to reflect the new version number.
> >    b) Adjust any necessary dependencies, etc., in debian/control.
> > 
> > 2) Build the package by running 'dpkg-buildpackage ...' in the
> >    source tree. This creates a bunch of files (including the binary
> >    .deb) in the parent directory.
> > 
> > 3) [Optional] Preferably, test the .deb to make sure it doesn't cause
> >    massive system breakage.
> > 
> > 4) Upload the generated package files in the parent directory by the
> >    build process, either by sending it to a sponsor or uploading it
> >    directly to the upload queue if you have upload access. The
> >    dupload script automatically determines which file(s) should be
> >    uploaded.
> > 
> > Once the package is uploaded successfully, the autobuilder infrastructure can be used to build the package for the umpteen architectures that Debian supports.
> > 
> > IIRC, once the package gets into the Debian archive it will eventually find its way into Ubuntu (and possibly the other Debian derivatives).
> 
> That works well for packages which are single source tree.  The current dmd, druntime, phobos, d-programming-language, tools separation makes that a little more challenging to put together, but not a lot.  It's probably worth doing regardless.  I realize that gdc and ldc are both in better shape in this area already.

You can always have separate packages that depend on each other.


> #4 there implies it's a source package, though I could be mis-interpreting you.  Is there a path for externally built binary packages?  That's fairly counter to the general distribution philosophy for most of them, so I'm giong to guess no.
[...]

As Iain said, you could follow the path of flash-installer-nonfree, which just contains a script that downloads the binaries from some URL upon installation. Of course, you'd still have to make sure that the downloaded binaries are installed in the correct places[1].

[1] See: http://wiki.debian.org/FilesystemHierarchyStandard


T

-- 
INTEL = Only half of "intelligence".
September 27, 2012
On 2012-09-27 11:46, Joseph Rushton Wakeling wrote:

> Would Debian have a problem with a dmd package in non-free?  Would
> Ubuntu have a problem with it in the multiverse or partner repositories?

Doesn't at least Ubuntu proprietary software, like drivers?

-- 
/Jacob Carlborg
September 27, 2012
On Thu, Sep 27, 2012 at 12:20:46AM -0700, Brad Roberts wrote:
> On 9/27/2012 12:02 AM, Iain Buclaw wrote:
[...]
> > For #4, yes.  Ubuntu is a better platform to approach for externally built binary-only packages.  But for debian, you could possibly do something similar to how eg: the flash-plugin installer package works - downloads the tar.gz/zip from an external site, extract and install / configure in system.
> 
> On reflection, #4 is not going to work for dmd.. neither ubuntu nor debian, nor most distributions are going to be happy with the license situation.  Nor are they happy with binary only packages anyway.  The right path is to do #4 but only for use on the dlang.org site (hosted via github's downloads api).  Then, add step #5 which is to automate source bundling and pushing to distributions.
[...]

Yeah that's the other way to do it: build your own .deb's, and create an apt repository on dlang.org (or somewhere), then publish the repository URL. Then users can simply add the URL to /etc/apt/sources.list, and they will be able to use apt-get/aptitude to directly download and install it. You can even include a file in /etc/apt/sources.list.d in your .deb, so that once users install it the first time, the next package upgrade will automatically pull any new versions from dlang.org.

As an example, this is what Opera does.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.