remove devel/{cudf,omake,ounit,ocaml-{cmdliner,cppo,dose,extlib,jsonm,re}} ?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Stuart Henderson
On 2019/04/02 11:50, Christopher Zimmermann wrote:

> On Tue, 2 Apr 2019 10:41:58 +0100
> Anil Madhavapeddy <[hidden email]> wrote:
>
> > I’m also working on a non-April fools joke, which is sufficient
> > metadata in dune to generate reliable openbsd ports. So in a few
> > months, we should be able to type in package names and have
> > reasonable Makefiles output for the ports (including WANTLIB etc).
> > Am doing it for Homebrew and a few other operating systems as well to
> > see if we can sidestep the port maintainer burden somewhat.  Unsure
> > yet if it’ll be suitable for usage in OpenBSD, but at a minimum it’ll
> > generate sufficient scaffolding for a human ports maintainer to tweak
> > for upstreaming.
>
> That's an interesting idea, I also thought about, but was wondering
> whether to generate the port from OPAM metadata or create a package
> from opam builds. This would obviously not integrate with the ports
> infrastructure. But would it even need to?
>
> Christopher

Adding support to portgen would be ideal ..

Adding something to directly build a package from outside ports
infrastructure is not so good

Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Ian Darwin
In reply to this post by Kenneth R Westerback-2
> Adding support to portgen would be ideal ..

Exactly what I was going to say, but Stuart beat me to it. This would be ideal for OpenBSD;
hopefully not too non-ideal for upstream.

> Adding something to directly build a package from outside ports
> infrastructure is not so good

Yup. And remember that OpenBSD ports cannot fetch files over the net during bulk
builds, so portgen is the best option, something else that builds a port in
the same manner is next (but why reinvent the thing?).

Installing outside of the ports system would be treated as renegade by the
project and as a pain in the arse for users. I also have a Mac and have to
install crap from Apple store, from brew, from at least one other other
ports system, directly from some vendors, some as .dmg and some as .pkg.
Updating is such a frickin' mess I have all but given up trying to keep that
system up to date! OBSD is the very best because you can just do pkg_add -vu
and update all third-party software.

Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Daniel Jakots-6
In reply to this post by Christopher Zimmermann-2
On Tue, 2 Apr 2019 11:50:32 +0200, Christopher Zimmermann
<[hidden email]> wrote:

> On Tue, 2 Apr 2019 10:41:58 +0100
> Anil Madhavapeddy <[hidden email]> wrote:
>
> > I’m also working on a non-April fools joke, which is sufficient
> > metadata in dune to generate reliable openbsd ports. So in a few
> > months, we should be able to type in package names and have
> > reasonable Makefiles output for the ports (including WANTLIB etc).
> > Am doing it for Homebrew and a few other operating systems as well
> > to see if we can sidestep the port maintainer burden somewhat.
> > Unsure yet if it’ll be suitable for usage in OpenBSD, but at a
> > minimum it’ll generate sufficient scaffolding for a human ports
> > maintainer to tweak for upstreaming.  
>
> That's an interesting idea, I also thought about, but was wondering
> whether to generate the port from OPAM metadata or create a package
> from opam builds. This would obviously not integrate with the ports
> infrastructure. But would it even need to?

You can look at sysutils/upt. It's not something specific for OpenBSD.
It works with "frontends" (language-specific packages systems, cpan pip
etc) and "backends" (OS-specific packages systems). There's already an
OpenBSD backend so you need to only add a ocaml frontend.

I used it for python ports and it does a lot of the grunt work.

cc (per his request) the author


Cheers,
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Kurt Mosiejczuk-9
On Tue, Apr 02, 2019 at 12:58:28PM -0400, Daniel Jakots wrote:

> > That's an interesting idea, I also thought about, but was wondering
> > whether to generate the port from OPAM metadata or create a package
> > from opam builds. This would obviously not integrate with the ports
> > infrastructure. But would it even need to?

> You can look at sysutils/upt. It's not something specific for OpenBSD.
> It works with "frontends" (language-specific packages systems, cpan pip
> etc) and "backends" (OS-specific packages systems). There's already an
> OpenBSD backend so you need to only add a ocaml frontend.

> I used it for python ports and it does a lot of the grunt work.

I'll also weigh in and say that upt works well. danj put me onto it and
I've used it to generate new python ports from pypi.

--Kurt

Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Anil Madhavapeddy-2
In reply to this post by Ian Darwin


> On 2 Apr 2019, at 13:12, Ian Darwin <[hidden email]> wrote:
>
>> Adding support to portgen would be ideal ..
>
> Exactly what I was going to say, but Stuart beat me to it. This would be ideal for OpenBSD;
> hopefully not too non-ideal for upstream.
>
>> Adding something to directly build a package from outside ports
>> infrastructure is not so good
>
> Yup. And remember that OpenBSD ports cannot fetch files over the net during bulk
> builds, so portgen is the best option, something else that builds a port in
> the same manner is next (but why reinvent the thing?).
>
> Installing outside of the ports system would be treated as renegade by the
> project and as a pain in the arse for users. I also have a Mac and have to
> install crap from Apple store, from brew, from at least one other other
> ports system, directly from some vendors, some as .dmg and some as .pkg.
> Updating is such a frickin' mess I have all but given up trying to keep that
> system up to date! OBSD is the very best because you can just do pkg_add -vu
> and update all third-party software.

portgen is _exactly_ what I was looking for, thanks!  I'll look into supporting
that first in the new dune infrastructure for this.

I'm the first user on my laptop, so I really want `pkg_add -u` to just work
for myself :-)

Anil

Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Cyril Roelandt
In reply to this post by Daniel Jakots-6
(I'm the author of upt. Please keep me CCed)

On 2019-04-02 12:58, Daniel Jakots wrote:
> You can look at sysutils/upt. It's not something specific for OpenBSD.
> It works with "frontends" (language-specific packages systems, cpan pip
> etc) and "backends" (OS-specific packages systems). There's already an
> OpenBSD backend so you need to only add a ocaml frontend.

That is a good summary of how upt works. The idea is that every time a
new frontend is added (for Hackage or NPM, for instance), minimal effort
is required to add support for it on the OpenBSD side. Support for PyPI
is just one simple class[1] and one short Jinja2 template[2].

Instead of writing a new backend for PortGen, you could write a new
frontend for upt :) It would also help package managers who use other
operating systems (hey, nobody's perfect!).

I'm willing to help with this if you're interested in using upt.

Regards,
Cyril

[1] https://framagit.org/upt/upt-openbsd/blob/master/upt_openbsd/upt_openbsd.py#L215
[2] https://framagit.org/upt/upt-openbsd/blob/master/upt_openbsd/templates/python.mk

Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Anil Madhavapeddy-2
On 2 Apr 2019, at 18:26, Cyril Roelandt <[hidden email]> wrote:

>
> (I'm the author of upt. Please keep me CCed)
>
> On 2019-04-02 12:58, Daniel Jakots wrote:
>> You can look at sysutils/upt. It's not something specific for OpenBSD.
>> It works with "frontends" (language-specific packages systems, cpan pip
>> etc) and "backends" (OS-specific packages systems). There's already an
>> OpenBSD backend so you need to only add a ocaml frontend.
>
> That is a good summary of how upt works. The idea is that every time a
> new frontend is added (for Hackage or NPM, for instance), minimal effort
> is required to add support for it on the OpenBSD side. Support for PyPI
> is just one simple class[1] and one short Jinja2 template[2].
>
> Instead of writing a new backend for PortGen, you could write a new
> frontend for upt :) It would also help package managers who use other
> operating systems (hey, nobody's perfect!).
>
> I'm willing to help with this if you're interested in using upt.

This also looks very cool!  How does it deal with mapping system
dependencies that a package needs into the ports Makefile?

opam has something called a 'depexts' field (see
https://github.com/ocaml/opam-depext <https://github.com/ocaml/opam-depext>) which records a mapping of
system OS package name that can be installed by that package
manager to satisfying C libraries that are needed.  That needs to
be mapped into the OpenBSD Makefile as well.

Anil
Reply | Threaded
Open this post in threaded view
|

Re: More OCaml ports for /dev/null?

Cyril Roelandt
On 2019-04-02 18:54, Anil Madhavapeddy wrote:

> On 2 Apr 2019, at 18:26, Cyril Roelandt <[hidden email]> wrote:
> >
> > (I'm the author of upt. Please keep me CCed)
> >
> > On 2019-04-02 12:58, Daniel Jakots wrote:
> >> You can look at sysutils/upt. It's not something specific for OpenBSD.
> >> It works with "frontends" (language-specific packages systems, cpan pip
> >> etc) and "backends" (OS-specific packages systems). There's already an
> >> OpenBSD backend so you need to only add a ocaml frontend.
> >
> > That is a good summary of how upt works. The idea is that every time a
> > new frontend is added (for Hackage or NPM, for instance), minimal effort
> > is required to add support for it on the OpenBSD side. Support for PyPI
> > is just one simple class[1] and one short Jinja2 template[2].
> >
> > Instead of writing a new backend for PortGen, you could write a new
> > frontend for upt :) It would also help package managers who use other
> > operating systems (hey, nobody's perfect!).
> >
> > I'm willing to help with this if you're interested in using upt.
>
> This also looks very cool!  How does it deal with mapping system
> dependencies that a package needs into the ports Makefile?

The frontend is OS-agnostic. It gathers metadata about a package, and
allows all backends (OpenBSD, Nix, Fedora...) to see metadata from
various package managers in a unified intermediate representation.

It is then up to the upt backends to map dependencies properly. For
instance, a Python package named "foo" upstream will be named "py-foo"
in OpenBSD. The OpenBSD backend could be modified to use depexts to
find all OS packages that need to be installed.


Cyril

12