On 18/07/2017 15:11, Daniel Bünzli wrote:
As for automation, it remains to be seen whether we want to map 1 opam package
to 1 Debian
package, or to map 1 git repo containing many opam packages to 1 Debian
package. The downside
of the first approach is similar to the above points. Also the
Daniel Bünzli writes:
>> I thought topkg-care is needed to run the tests, for instance,
>> for cmdliner?
>
> In fact no, the `topkg` tool is really just a convenience as far as
OK, I'll keep this in mind and will have a closer look when I
look at the tests.
On 18 July 2017 at 23:16:03, Hendrik Tews (hend...@askra.de) wrote:
> Everybody,
>
> I am a bit shocked that my simple question about how to best
> package topkg and topkg-care lead to such a heated and quite
> personal discussion. I would rather prefer to have a friendly and
> constructive
Everybody,
I am a bit shocked that my simple question about how to best
package topkg and topkg-care lead to such a heated and quite
personal discussion. I would rather prefer to have a friendly and
constructive relation to our upstream providers and to base
discussions on technical arguments.
On 18 July 2017 at 14:09:36, Ximin Luo (infini...@debian.org) wrote:
> In Debian they have to go in two separate source packages, because the
> distributed nature
> of package building means (if it were in a single source package) we can't
> run the build
> for topkg, run the build for
Daniel Bünzli:
> On 18 July 2017 at 10:42:51, Hendrik Tews (hend...@askra.de) wrote:
>
>> Preparing Debian packages would of course be much more straightforward, if
>> topkg and
>> topkg-care would not share the same source tarball ;-)
>
> I am a bit curious on why this is the case exactly.
On 18 July 2017 at 10:42:51, Hendrik Tews (hend...@askra.de) wrote:
> Preparing Debian packages would of course be much more straightforward, if
> topkg and
> topkg-care would not share the same source tarball ;-)
I am a bit curious on why this is the case exactly. What kind of difficulties
Daniel Bünzli writes:
> Please note that there is no circular dependency. There are two
> different opam packages: topkg and topkg-care with different build
> instructions and each package should be built on its own, as done in
> opam. See the topkg.opam and
Hello Hendrik,
Please note that there is no circular dependency. There are two different opam
packages: topkg and topkg-care with different build instructions and each
package should be built on its own, as done in opam. See the topkg.opam and
topkg-care.opam files for a precise definition of
Hendrik Tews:
>
>>> I just see: topkg depends on Fmt, Logs, Bos, Cmdliner and
>>> opam-format. Out of this only cmlliner is currently in Debian,
>>> right?
>
> There is some kind of circular build dependency:
>
> - topkg contains the topkg library and the topkg-care tool
> - building the topkg
>> I just see: topkg depends on Fmt, Logs, Bos, Cmdliner and
>> opam-format. Out of this only cmlliner is currently in Debian,
>> right?
There is some kind of circular build dependency:
- topkg contains the topkg library and the topkg-care tool
- building the topkg library requires nothing
-
Stéphane Glondu:
> On 16/07/2017 22:15, Hendrik Tews wrote:
IMO, a proper solution would require packaging topkg and, in the
long run, also odig. What do you think?
>>>
>>> I agree. Feel free to do it! I'm not planning to do it right now, unless
>>> it is absolutely necessary for the
On 16/07/2017 22:15, Hendrik Tews wrote:
IMO, a proper solution would require packaging topkg and, in the
long run, also odig. What do you think?
I agree. Feel free to do it! I'm not planning to do it right now, unless
it is absolutely necessary for the transition.
I just see: topkg depends
Stéphane Glondu writes:
>> IMO, a proper solution would require packaging topkg and, in the
>> long run, also odig. What do you think?
>
> I agree. Feel free to do it! I'm not planning to do it right now, unless
> it is absolutely necessary for the transition.
I just see:
>> IMO, a proper solution would require packaging topkg and, in the
>> long run, also odig. What do you think?
>
> I agree. Feel free to do it! I'm not planning to do it right now, unless
> it is absolutely necessary for the transition.
OK, unless you have another suggestion how I could
On 15/07/2017 22:17, Hendrik Tews wrote:
> I looked into updating the cmdliner package for the new upstream
> version 1.0.0. This new version uses topkg
> (http://erratique.ch/software/topkg) for building and it seems
> that the documentation is generated with odig
>
16 matches
Mail list logo