to package deimos project that is not really easy
  each module has his repo
  each module should to be builded not in same way

That is a good project but it need more standard

firstly you can to provide a makefile by example this one
https://github.com/bioinfornatics/MakefileForD like this you
provide a uniq way to build it and tosupport all compiller. All
os provide a make build system somewhere.

You can choose an other way the main idea that is to help
packager to package this huge project. Because once time is
packaged you need to maintain it!

Please do anything in this way

thanks

use a repo named deimos in more of projectname and to use git submodule + a build system to build all deimos module sound like a good thing

On Wednesday, July 17, 2013 22:40:58 bioinfornatics wrote:
> to package deimos project that is not really easy
> each module has his repo
> each module should to be builded not in same way

While I don't necessarily disagree that how deimos is done needs some work, I don't see why you would ever need to package deimos. It contains disparate libraries that aren't necessarily intended to be used together at all (and potentially can't be - e.g. if one were Linux-specific and another were Windows-specific). Having the deimos project is useful, because it gives us one place to look for D bindings for C libraries, but the libraries in there are otherwise completely unrelated to each other and thus packaging them together really doesn't make sense IMHO.

Several of them are set up to use dub though, which makes grabbing them much easier. I think that my biggest gripe with how Deimos is set up is that the folks who manage the projects in there aren't in control of them. So, they can't merge anything themselves or do other git commands such as tagging or branching. Some of the Phobos devs do have merge rights, but that doesn't make it so that they can do other stuff like tagging or branching. So, the result is that only a few people (like Walter and probably Andrei) can do all of the various stuff to those repos that a repo maintainer might want to do (like branching), and yet the only reason that they're grouped together in the first place is searchability. So, we've gained the searchability at the cost of flexibility. But I don't know how to fix that aside maybe from Walter giving full permissions/access to a deimos repo to its primary maintainer (without giving them permissions to other deimos repos), but I don't know what github will or won't allow you to do in that regard.

- Jonathan M Davis

On Wednesday, 17 July 2013 at 21:01:16 UTC, Jonathan M Davis wrote:
> On Wednesday, July 17, 2013 22:40:58 bioinfornatics wrote:
>> to package deimos project that is not really easy
>> each module has his repo
>> each module should to be builded not in same way
>
> While I don't necessarily disagree that how deimos is done needs some work, I
> don't see why you would ever need to package deimos. It contains disparate
> libraries that aren't necessarily intended to be used together at all (and
> potentially can't be - e.g. if one were Linux-specific and another were
> Windows-specific). Having the deimos project is useful, because it gives us one
> place to look for D bindings for C libraries, but the libraries in there are
> otherwise completely unrelated to each other and thus packaging them together
> really doesn't make sense IMHO.
>
> Several of them are set up to use dub though, which makes grabbing them much
> easier. I think that my biggest gripe with how Deimos is set up is that the
> folks who manage the projects in there aren't in control of them. So, they
> can't merge anything themselves or do other git commands such as tagging or
> branching. Some of the Phobos devs do have merge rights, but that doesn't make
> it so that they can do other stuff like tagging or branching. So, the result is
> that only a few people (like Walter and probably Andrei) can do all of the
> various stuff to those repos that a repo maintainer might want to do (like
> branching), and yet the only reason that they're grouped together in the first
> place is searchability. So, we've gained the searchability at the cost of
> flexibility. But I don't know how to fix that aside maybe from Walter giving
> full permissions/access to a deimos repo to its primary maintainer (without
> giving them permissions to other deimos repos), but I don't know what github
> will or won't allow you to do in that regard.
>
> - Jonathan M Davis

I agree with your point of view.

I package for a linux distro so maintain one package which sync each module to current stable is more easy to maintain versus maintain x module .
I do not know dub i will take a look if is an irtaller system for user or it could to be used to do a package

example:
if they are one meta project :
- create 1 package with sub-package (or meta-package)
- git pull or downlobd latest archive once time
- building in 1 shot whole linux deimos project
- push 1 update

package separately each package will eat all my free time to maintain it

Firstly dub is not into fedora

# yum provides /usr/bin/dub
No matches found

# yum provides */dub
No matches found

So i need to find the project build it provide a package submit a review to go to official repo before to start to package one module

On Wednesday, July 17, 2013 23:10:00 bioinfornatics wrote:
> I package for a linux distro so maintain one package which sync
> each module to current stable is more easy to maintain versus
> maintain x module .
> I do not know dub i will take a look if is an irtaller system for
> user or it could to be used to do a package

But the deimos project just provides bindings, not libraries, so the only reason to have them is for development, and there's generally no reason to build them separate from your program. As such, I see little point in including them in a distro's packaging system, not when we're already looking to have a package manager for D development packages. And I really don't agree with the idea of grouping them all together to be grabbed together anyway, because they're all completely unrelated. You wouldn't create a single rpm or deb for all of the dev packages on a Linux distro would you? Granted, that would be larger than packaging deimos (even if deimos had bindings for all of the same dev packages), because it would include more than just bindings, but it's the same concept.

This is a prime example of where a package manager for D makes sense and distro packages do not, and many of the deimos projects are included in the dub registry, so whether or not dub ever becomes either the actual or de facto standard for D packages, it's at least usable at this point and is definitely gaining adoption.

- Jonathan M Davis

On Wednesday, July 17, 2013 23:25:23 bioinfornatics wrote:
> Firstly dub is not into fedora
> 
> # yum provides /usr/bin/dub
> No matches found
> 
> # yum provides */dub
> No matches found
> 
> So i need to find the project build it provide a package submit a review to go to official repo before to start to package one module

https://github.com/rejectedsoftware/dub

- Jonathan M Davis

On 07/17/2013 11:00 PM, Jonathan M Davis wrote:
> I think that my biggest gripe with how Deimos is set up is that the folks who manage the projects in there aren't in control of them. So, they can't merge anything themselves or do other git commands such as tagging or branching.

Is it not possible to set up something where

   (i) Deimos library devs create a 'home repo' for their project, which can
       be a personal repo, a group repo, or even something not on GitHub if
       they prefer

  (ii) Deimos project repos just do a regular, automated clone/pull from the
       specified home repo.

On Thursday, July 18, 2013 08:10:35 Joseph Rushton Wakeling wrote:
> On 07/17/2013 11:00 PM, Jonathan M Davis wrote:
> > I think that my biggest gripe with how Deimos is set up is that the folks who manage the projects in there aren't in control of them. So, they can't merge anything themselves or do other git commands such as tagging or branching.
> 
> Is it not possible to set up something where
> 
>    (i) Deimos library devs create a 'home repo' for their project, which can
> be a personal repo, a group repo, or even something not on GitHub if they
> prefer

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). 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. We could certainly change what it means for something to be in deimos (e.g. Jakob Ovrum suggested recently that we turn it into a wiki page which refers to repos which are not part of any particular github organization and which could belong to any developer, not just those picked by Walter or the other main dmd/druntime/Phobos devs), but at present, what deimos is is defined by the github organization 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.

I really don't know what the best approach would be for deimos. What we have currently is working on some level, but clearly there's some room for improvement. I think that there's plenty of room for suggestions.

- Jonathan M Davis