caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Re: [Caml-list] Re: opam packages wrapped inside a spec file
@ 2013-05-30 19:37 Florent Monnier
  2013-05-30 20:11 ` Malcolm Matalka
  0 siblings, 1 reply; 2+ messages in thread
From: Florent Monnier @ 2013-05-30 19:37 UTC (permalink / raw)
  To: Francois Berenger; +Cc: caml-list

2013/05/30, Francois Berenger wrote:
> On 05/30/2013 06:29 AM, Florent Monnier wrote:
[...]
>> For fun I've played with wrapping an opam package inside a rpm package.
>> I just have to tar.gz the package directory and in the .spec file, sed
>> the archive field for a file:// path (because not allowed to get
>> something from outside) seded with the archives in the SOURCES
>> directory of the rpm package. I init Opam and repo remove the internet
>> one (again nothing from outside), then install in the path that
>> rpmbuild wants.
>> There is still one detail that won't be able to be done by a script
>> it's when there's a C lib dependency, because Opam don't provide yet
>> any feature for this. But this will probably come for 2.0. So it's
>> potentially possible to create .rpm's for all Opam packages with
>> almost no or very few human work. This kind of rpm's won't fit the
>> Mageia packaging policy though, but we could change it to allow this,
>> or put an unofficial rpm repo somewhere else.
>
> Will this procedure be automated?
>
> Automatic creation of RPMs from OPAM packages.
> I am very interested by this.

Here is the early result of playing with this:
http://www.linux-nantes.org/%7Efmonnier/ocaml/opam/wrap-rpm/
you can see it's only the opam package wrapped inside a .spec file.

A more clean solution would of course to make an opam2spec script to
really create a .spec file that would look very close to a human made
.spec file. But I think that this second solution would need more
human work thant the dirty one. This second would maybe even take as
many time as if it's completely made by hand because there would be
more details to edit I think.

And the dirty wrap method has also the advantage to stay very close to
the original one.

> Will this procedure be automated?

This one seems to give an acceptable result.
(only README LICENSE and api-doc are missing)
I guess this one could be used as a template by a script for the others.

> Automatic creation of RPMs from OPAM packages.
> I am very interested by this.

need to add the homepages and licenses fields in opam files if we want
this script to be able to fill the equivalent fields of the .spec
files.
Also the C lib dependency needs to be found to add the BuildRequires fields.
Otherwise it seems that most of it can be automated.

--

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Caml-list] Re: opam packages wrapped inside a spec file
  2013-05-30 19:37 [Caml-list] Re: opam packages wrapped inside a spec file Florent Monnier
@ 2013-05-30 20:11 ` Malcolm Matalka
  0 siblings, 0 replies; 2+ messages in thread
From: Malcolm Matalka @ 2013-05-30 20:11 UTC (permalink / raw)
  To: Florent Monnier; +Cc: Francois Berenger, caml-list

Have you looked at fpm (https://github.com/jordansissel/fpm) for
producing RPMs and debs from an arbitrary directory structure?

/M

Florent Monnier <monnier.florent@gmail.com> writes:

> 2013/05/30, Francois Berenger wrote:
>> On 05/30/2013 06:29 AM, Florent Monnier wrote:
> [...]
>>> For fun I've played with wrapping an opam package inside a rpm package.
>>> I just have to tar.gz the package directory and in the .spec file, sed
>>> the archive field for a file:// path (because not allowed to get
>>> something from outside) seded with the archives in the SOURCES
>>> directory of the rpm package. I init Opam and repo remove the internet
>>> one (again nothing from outside), then install in the path that
>>> rpmbuild wants.
>>> There is still one detail that won't be able to be done by a script
>>> it's when there's a C lib dependency, because Opam don't provide yet
>>> any feature for this. But this will probably come for 2.0. So it's
>>> potentially possible to create .rpm's for all Opam packages with
>>> almost no or very few human work. This kind of rpm's won't fit the
>>> Mageia packaging policy though, but we could change it to allow this,
>>> or put an unofficial rpm repo somewhere else.
>>
>> Will this procedure be automated?
>>
>> Automatic creation of RPMs from OPAM packages.
>> I am very interested by this.
>
> Here is the early result of playing with this:
> http://www.linux-nantes.org/%7Efmonnier/ocaml/opam/wrap-rpm/
> you can see it's only the opam package wrapped inside a .spec file.
>
> A more clean solution would of course to make an opam2spec script to
> really create a .spec file that would look very close to a human made
> .spec file. But I think that this second solution would need more
> human work thant the dirty one. This second would maybe even take as
> many time as if it's completely made by hand because there would be
> more details to edit I think.
>
> And the dirty wrap method has also the advantage to stay very close to
> the original one.
>
>> Will this procedure be automated?
>
> This one seems to give an acceptable result.
> (only README LICENSE and api-doc are missing)
> I guess this one could be used as a template by a script for the others.
>
>> Automatic creation of RPMs from OPAM packages.
>> I am very interested by this.
>
> need to add the homepages and licenses fields in opam files if we want
> this script to be able to fill the equivalent fields of the .spec
> files.
> Also the C lib dependency needs to be found to add the BuildRequires fields.
> Otherwise it seems that most of it can be automated.
>
> --

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-05-30 20:11 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-30 19:37 [Caml-list] Re: opam packages wrapped inside a spec file Florent Monnier
2013-05-30 20:11 ` Malcolm Matalka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).