On 07/18/2013 08:35 AM, Jonathan M Davis wrote:
> As it stands, Deimos is a github organization (named D-Programming-Deimos to be precise) and for anything to be in Deimos, it must be in that github organization, which means that the repo is owned by that organization, and only members of that organization have any permissions for it (and the permissions can vary from member to member).

Yes, I understand that.

> So, while someone can certainly manage D bindings for a C library in their own repo, it's not really part of Deimos unless it's in a repo in D-Programming-Deimos.

Yes, but there's a difference between "an up-to-date clone of the project repo is stored in D-Programming-Deimos" versus "the merging and pull requests and other project management have to be carried out in D-Programming-Deimos."

>>   (ii) Deimos project repos just do a regular, automated clone/pull from the
>> specified home repo.
> 
> It might be possible to create a tool to do something like that, but AFAIK, nothing like that currently exists. But if you were going to treat a particular person's repo as essentially the official one (as it's where the deimos one gets its stuff), then you probably might as well just take the approach of giving that person full access to the deimos repo in question rather than bothering with such a tool.

Depends on what options GitHub gives you.  If you can't give someone control over a single repo in Deimos without giving them effective control over all the others, then independent project repos + clone to D-Programming-Deimos might be an OK way to organize it.  Seems better to me than a Wiki page list, because this way you have direct access to the code from the Deimos project list.

It also gives Deimos admins a way to easily exclude projects that are proving problematic -- just delete the Deimos clone of the project repo.

On Thursday, July 18, 2013 09:09:09 Joseph Rushton Wakeling wrote:
> Depends on what options GitHub gives you.  If you can't give someone control over a single repo in Deimos without giving them effective control over all the others, then independent project repos + clone to D-Programming-Deimos might be an OK way to organize it.

I'm sure that it's possible to give per-repo permissions, because I have full commit access to Phobos and druntime but no commit access whatsoever to dmd, and they're all in the same github org. But I don't know how fine-grained the permissions controls are or how much they can ultimately do.

- Jonathan M Davis

after taking a look about dub source code. I do not think dun is
the way to go. Maybe i misunderstanding something.  This project
do not follow FHS: https://wiki.linuxfoundation.org/en/FHS.

at line 73
https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L73
dub path are set to "/var/lib/dub/"

and at line 195
https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L195
  install path is set to "/var/lib/dub/packages/"

Any serious linux distro should to accept this to their official
repo. Then all d project which provides only dub as installer
will fail grow.

Maybe i misunderstood somewhere just show me

On Thursday, 18 July 2013 at 07:36:48 UTC, bioinfornatics wrote:
> after taking a look about dub source code. I do not think dun is
> the way to go. Maybe i misunderstanding something.  This project
> do not follow FHS: https://wiki.linuxfoundation.org/en/FHS.
>
> at line 73
> https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L73
> dub path are set to "/var/lib/dub/"
>
> and at line 195
> https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L195
>   install path is set to "/var/lib/dub/packages/"
>
> Any serious linux distro should to accept this to their official
> repo. Then all d project which provides only dub as installer
> will fail grow.
>
> Maybe i misunderstood somewhere just show me

Any serious linux distro should not* to accept this to their
official repo.

On Thursday, July 18, 2013 09:37:52 bioinfornatics wrote:
> On Thursday, 18 July 2013 at 07:36:48 UTC, bioinfornatics wrote:
> > after taking a look about dub source code. I do not think dun is the way to go. Maybe i misunderstanding something.  This project do not follow FHS: https://wiki.linuxfoundation.org/en/FHS.
> > 
> > at line 73 https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L73 dub path are set to "/var/lib/dub/"
> > 
> > and at line 195 https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L195
> > 
> >   install path is set to "/var/lib/dub/packages/"
> > 
> > Any serious linux distro should to accept this to their official repo. Then all d project which provides only dub as installer will fail grow.
> > 
> > Maybe i misunderstood somewhere just show me
> 
> Any serious linux distro should not* to accept this to their official repo.

Except that none of this is supposed to even be in a Linux distro. None of it would ever be in a Linux package or be installed in /usr or /var or any of that. These are development packages, not actual programs, so there's no reason to even have them installed by the distro in the main system. You only need them to build your own software.

Now, that's a bit different if you're dealing with shared libraries (which we'll have soon), and at that point, dub (or any other D package manager) would potentially have to worry about looking at what's installed on the system in some standard manner, and shared D libraries would be installed with Linux packages. But for anything you'd be doing now, that's completely irrelevant, because there's no benefit in installing any of it in the system as a whole. This is particularly true for deimos projects which don't even generate static libraries. They've basically just the D equivalent of a bunch of include files.

So, I don't think that discussing installing deimos with a linux package (such as an rpm or deb) makes any sense at all. At this point, the only D stuff that it makes sense to make Linux packages for is applications. In the future, it'll make sense for shared libraries, and package tools like dub will have to adapt deal with that, but for the moment, since shared library support in D is in its infancy, it's pretty much a non-issue.

We _could_ make linux packages for static libraries, but there's really not much benefit in doing so, particularly when D compiles so quickly, and you pretty much have to have built everything with the same version of dmd. But not even that applies to deimos, since it just provides bindings.

- Jonathan M Davis

On Thursday, July 18, 2013 01:59:54 Jonathan M Davis wrote:
> On Thursday, July 18, 2013 09:37:52 bioinfornatics wrote:
> > On Thursday, 18 July 2013 at 07:36:48 UTC, bioinfornatics wrote:
> > > after taking a look about dub source code. I do not think dun is the way to go. Maybe i misunderstanding something.  This project do not follow FHS: https://wiki.linuxfoundation.org/en/FHS.
> > > 
> > > at line 73 https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L73 dub path are set to "/var/lib/dub/"
> > > 
> > > and at line 195 https://github.com/rejectedsoftware/dub/blob/master/source/dub/dub.d#L19 5
> > > 
> > >   install path is set to "/var/lib/dub/packages/"
> > > 
> > > Any serious linux distro should to accept this to their official repo. Then all d project which provides only dub as installer will fail grow.
> > > 
> > > Maybe i misunderstood somewhere just show me
> > 
> > Any serious linux distro should not* to accept this to their official repo.
> 
> Except that none of this is supposed to even be in a Linux distro. None of it would ever be in a Linux package or be installed in /usr or /var or any of that. These are development packages, not actual programs, so there's no reason to even have them installed by the distro in the main system. You only need them to build your own software.
> 
> Now, that's a bit different if you're dealing with shared libraries (which we'll have soon), and at that point, dub (or any other D package manager) would potentially have to worry about looking at what's installed on the system in some standard manner, and shared D libraries would be installed with Linux packages. But for anything you'd be doing now, that's completely irrelevant, because there's no benefit in installing any of it in the system as a whole. This is particularly true for deimos projects which don't even generate static libraries. They've basically just the D equivalent of a bunch of include files.
> 
> So, I don't think that discussing installing deimos with a linux package (such as an rpm or deb) makes any sense at all. At this point, the only D stuff that it makes sense to make Linux packages for is applications. In the future, it'll make sense for shared libraries, and package tools like dub will have to adapt deal with that, but for the moment, since shared library support in D is in its infancy, it's pretty much a non-issue.
> 
> We _could_ make linux packages for static libraries, but there's really not much benefit in doing so, particularly when D compiles so quickly, and you pretty much have to have built everything with the same version of dmd. But not even that applies to deimos, since it just provides bindings.

I would also point out that a number of other languages (e.g. ruby, haskell, and perl) have package managers for downloading code to use and which may or may not be integrated into Linux packages. And it's that sort of thing that we're looking to emulate. Then you can just build your program without having to track all of the dependencies down. The D package manager would just do that for you.

- Jonathan M Davis

firstly fedora provide D shared lib since 2 years and static lib is not allowed.
We want to get one lib and share it to each application.

Secondly deimos provide include file these should not to be embed by each application which need it. that duplicate file in more some same file will not be at same revision that is not linux philosophy.

Third, about package manager:
 - this is for user not distro linux
 - setuptools from python use FHS
 - cpan from perl it is used by user not by packager
 - rvm (ruby ) ditto

so they are 2 things:
 - builder should to build
 - package manager should to package

problem here that is dub is showed to be the universal D way to build and manage packaging. that is really a problem to continue to support D project into offcial linux repository.

I can package dub and user use it for any reason but i need to be able to build and install a project by following FHS and other linux rules

On Thursday, 18 July 2013 at 09:00:23 UTC, Jonathan M Davis wrote:
> ...

There are two distinct issues here:

1) The fact that stuff dub installs stuff without the help of package manager does not mean it can ignore FHS guidelines - otherwise one will have a hard time adopting dub itself into repository. At the very least its place is /opt/dub but I'd actually expect it to split stuff over /usr/local. Will likely need to have a look at it if ever want to create such package.

2) Convenience for packager. However, I don't think this is much of an issue. One can always clone Deimos repository and enhance DFLAGS accordingly in a packaging script. As Deimos modules are used only during the build process and are not supposed to be provided to the end user, it is just a minor maintenance inconvenience. Nothing critical.

There are, of course, library packages like vibe.d which do include full source code and require availability of Deimos bindings to be used. But I think packing a bindings copy with the library itself is a proper way to go here, unless they actually get exposed to programmer as part of library API (have not met a single example so far).

On Thursday, 18 July 2013 at 09:47:27 UTC, bioinfornatics wrote:
> problem here that is dub is showed to be the universal D way to build and manage packaging. that is really a problem to continue to support D project into offcial linux repository.
>
It really isn't.  It may become that if the community decides to adopt it officially, but for the time being, it's third-party code maintained as part of vibe.d.

> I can package dub and user use it for any reason but i need to be able to build and install a project by following FHS and other linux rules

Your job as a distro package maintainer is to package software for your distro; make sure the package interacts well with the system, such as by making sure it builds with the proper CFLAGS, works with --as-needed, installs files to the proper place, etc.; and, within a reasonable degree of certainty, ensure it won't break users' systems.

If it's not installing files in the right places, patch it.  Then, contact the maintainers to see if you can have that patch upstreamed.  It's not a project's job to package software-- those that manage to do it and do it well are fortunate; in my experience, many of them are awful at it (especially LSI).  Sometimes you'll need to help them understand what distros need so they can keep distro needs in mind going forward.  It's a two-way street.

-Wyatt

> Your job as a distro package maintainer is to package software for your distro; make sure the package interacts well with the system, such as by making sure it builds with the proper CFLAGS, works with --as-needed, installs files to the proper place, etc.; and, within a reasonable degree of certainty, ensure it won't break users' systems.
>
> If it's not installing files in the right places, patch it.  Then, contact the maintainers to see if you can have that patch upstreamed.  It's not a project's job to package software-- those that manage to do it and do it well are fortunate; in my experience, many of them are awful at it (especially LSI).  Sometimes you'll need to help them understand what distros need so they can keep distro needs in mind going forward.  It's a two-way street.
>
> -Wyatt

I know my jobs ;-)

if we can start something which satisfy everyone that is good (dev / user / distro ).

I exposing what could to be a problem. If D lib start to be a nightmare to package that will not help to continue to package it.

Lib should not to embed deimos import file we wills pent lot of time to patch every build system.

So the original question about deimos is closed i will package
- vibe.d ( building manually erf ... ),
- corresponding deimos dependencies
- dub to be used as cpan