FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 01-04-2011, 03:46 PM
Xyne
 
Default Ocaml Packages

Thomas S Hatch wrote:

> Sounds good, in the case of OCaml libs, using the libs will
> almost always require the ocaml package, actually, the only cases where it
> would not is if the upstream maintainer is not producing bytecode and native
> bins, which they always should. So you are most likely correct in that we
> should recommended ocaml as a dep and a makedep, and I think we should keep
> the naming, not only because of the ocaml dependencies, but also to
> distinguish them from the C libs, it would not take long before we started
> to see naming conflicts since many libs provide the same functions by the
> same names.

Sorry, I should have been clearer in my previous message. A package should
*never* appear in both the depends and the makedepends array. If a package is
required both to build and to run it, it should appear in, and only in, the
depends array. If it's only needed to build the package but not to run it then
it should be in the makedepends array.

I have edited the Wiki page to remove "ocaml" from the makedepends array.

Perhaps it should be made clearer on the wiki page that the example PKGBUILD is
only for OCaml libraries.


> So with that said I think I need to clarify that packages like virt-top (
> http://aur.archlinux.org/packages.php?ID=44978) which distribute only a
> native executable need to NOT be called ocaml-virt-top but since the libs
> should distribute code for all three layers and that running said code
> requires the ocaml package.

*nods*

> Also I am trying to bring the conventions inline with the way they were
> created by Richard Jones for Red Hat, since they are very clean and Richard
> Jones is one of the main OCaml heads.
>
> Does that make sense? I think that you are right on the depends for libs,
> and that the naming should stay ocaml-foo for libs. But clarify in the docs
> that OCaml applications should be treated like normal applications since
> they should not require ocaml.

*nods again*

>
> The viable confusion comes in where an end user application is built in such
> a way that it uses the bytecode - I have never seen this, but it is
> possible.

If the bytecode were an application then I would not include the "ocaml-"
prefix in the name, assuming that no libraries were included.

The "ocaml-" prefix should indicate that the package is for working with OCaml,
i.e. that it provides something which is only useful to an OCaml coder, which
will normally be a library, or something else that you can import in your code.

If the package provides a an executable that the user can use without caring
about the language behind it, then it should not contain the prefix. That
applies to bytecode as well, as the user need not be concerned with the
underlying code.

For packages that mix both libraries and applications, it can go either way. I
would opt for using the prefix in that case to indicate the presence of
libraries, but I know that there are some Haskell packages which use the
binary's name without the "haskell-" prefix despite the inclusion of libraries.

There's probably a better, pithier way to express this, but it eludes me right
now.
 
Old 01-04-2011, 04:11 PM
Thomas S Hatch
 
Default Ocaml Packages

On Tue, Jan 4, 2011 at 9:46 AM, Xyne <xyne@archlinux.ca> wrote:

> Thomas S Hatch wrote:
>
> > Sounds good, in the case of OCaml libs, using the libs will
> > almost always require the ocaml package, actually, the only cases where
> it
> > would not is if the upstream maintainer is not producing bytecode and
> native
> > bins, which they always should. So you are most likely correct in that we
> > should recommended ocaml as a dep and a makedep, and I think we should
> keep
> > the naming, not only because of the ocaml dependencies, but also to
> > distinguish them from the C libs, it would not take long before we
> started
> > to see naming conflicts since many libs provide the same functions by the
> > same names.
>
> Sorry, I should have been clearer in my previous message. A package should
> *never* appear in both the depends and the makedepends array. If a package
> is
> required both to build and to run it, it should appear in, and only in, the
> depends array. If it's only needed to build the package but not to run it
> then
> it should be in the makedepends array.
>
> I have edited the Wiki page to remove "ocaml" from the makedepends array.
>
> Perhaps it should be made clearer on the wiki page that the example
> PKGBUILD is
> only for OCaml libraries.
>
>
> > So with that said I think I need to clarify that packages like virt-top (
> > http://aur.archlinux.org/packages.php?ID=44978) which distribute only a
> > native executable need to NOT be called ocaml-virt-top but since the libs
> > should distribute code for all three layers and that running said code
> > requires the ocaml package.
>
> *nods*
>
> > Also I am trying to bring the conventions inline with the way they were
> > created by Richard Jones for Red Hat, since they are very clean and
> Richard
> > Jones is one of the main OCaml heads.
> >
> > Does that make sense? I think that you are right on the depends for libs,
> > and that the naming should stay ocaml-foo for libs. But clarify in the
> docs
> > that OCaml applications should be treated like normal applications since
> > they should not require ocaml.
>
> *nods again*
>
> >
> > The viable confusion comes in where an end user application is built in
> such
> > a way that it uses the bytecode - I have never seen this, but it is
> > possible.
>
> If the bytecode were an application then I would not include the "ocaml-"
> prefix in the name, assuming that no libraries were included.
>
> The "ocaml-" prefix should indicate that the package is for working with
> OCaml,
> i.e. that it provides something which is only useful to an OCaml coder,
> which
> will normally be a library, or something else that you can import in your
> code.
>
> If the package provides a an executable that the user can use without
> caring
> about the language behind it, then it should not contain the prefix. That
> applies to bytecode as well, as the user need not be concerned with the
> underlying code.
>
> For packages that mix both libraries and applications, it can go either
> way. I
> would opt for using the prefix in that case to indicate the presence of
> libraries, but I know that there are some Haskell packages which use the
> binary's name without the "haskell-" prefix despite the inclusion of
> libraries.
>
> There's probably a better, pithier way to express this, but it eludes me
> right
> now.
>

That clears a few things up, I have some packages to fix
I have been looking at the depends and the makdedepends in the redhat
Requires and BuildRequires sense! Sometimes I forget that simplicity rules!
(I don't know if I mentioned this but I used to work for Red Hat, some
axioms die hard )

As for your explanation of the naming I completely agree, although I would
sway towards naming a package only by it's name and not by ocaml-foo if the
package provides an application that just happens to include libs. Thats
like saying that every python package should be named python-foo, unless the
package consists of just a script.

I will chew on this info and figure out a better way to express this info on
the wiki.

-Tom
 
Old 01-04-2011, 08:16 PM
Xyne
 
Default Ocaml Packages

Thomas S Hatch wrote:

> As for your explanation of the naming I completely agree, although I would
> sway towards naming a package only by it's name and not by ocaml-foo if the
> package provides an application that just happens to include libs. Thats
> like saying that every python package should be named python-foo, unless the
> package consists of just a script.

I see your point and partially agree. I would say that it depends on whether
the libraries or the application are the principle component of the package.

I was thinking of Haskell packages when I wrote that, and haskell-pandoc in
particular. It includes modules that can be used in Haskell code but it also
includes a full application. It really could be named either way but I think
it's useful to indicate the presence of modules intended for general use with
the prefix.

Of course, if an application required its own libraries or modules to run and
those were not intended to be used by anything else then I would agree that
there should be no prefix.

Perhaps the ideal would be to split some packages to provide the libraries and
application separately. (I'm just thinking out loud here.)

Regards,
Xyne
 
Old 01-04-2011, 09:10 PM
Thomas S Hatch
 
Default Ocaml Packages

On Tue, Jan 4, 2011 at 2:16 PM, Xyne <xyne@archlinux.ca> wrote:

> Thomas S Hatch wrote:
>
> > As for your explanation of the naming I completely agree, although I
> would
> > sway towards naming a package only by it's name and not by ocaml-foo if
> the
> > package provides an application that just happens to include libs. Thats
> > like saying that every python package should be named python-foo, unless
> the
> > package consists of just a script.
>
> I see your point and partially agree. I would say that it depends on
> whether
> the libraries or the application are the principle component of the
> package.
>
> I was thinking of Haskell packages when I wrote that, and haskell-pandoc in
> particular. It includes modules that can be used in Haskell code but it
> also
> includes a full application. It really could be named either way but I
> think
> it's useful to indicate the presence of modules intended for general use
> with
> the prefix.
>
> Of course, if an application required its own libraries or modules to run
> and
> those were not intended to be used by anything else then I would agree that
> there should be no prefix.
>
> Perhaps the ideal would be to split some packages to provide the libraries
> and
> application separately. (I'm just thinking out loud here.)
>
> Regards,
> Xyne
>
>
>
Yes, this is an ongoing issue, and it starts to scrape the question of a lot
of package splitting with -devel packages. I think it would be safe in
saying that that in general Arch does not do -devel packages, and it would
be silly to start devel packages our here on the ocaml front!

But this sounds good, I think I that finding some solid ground on this
little grey area will be the last part to the standard, I think I will ask
Richard Jones what he thinks (although he will give me some crap about arch
not splitting devel packages )

-Tom
 
Old 01-05-2011, 10:32 AM
Xyne
 
Default Ocaml Packages

Thomas S Hatch wrote:

> Yes, this is an ongoing issue, and it starts to scrape the question of a lot
> of package splitting with -devel packages. I think it would be safe in
> saying that that in general Arch does not do -devel packages, and it would
> be silly to start devel packages our here on the ocaml front!
>
> But this sounds good, I think I that finding some solid ground on this
> little grey area will be the last part to the standard, I think I will ask
> Richard Jones what he thinks (although he will give me some crap about arch
> not splitting devel packages )
>
> -Tom

I wasn't actually suggesting that we split the packages (whence the inclusion
of "Perhaps the ideal..."). I was just considering whether there would be any
advantages to that approach. The advent of split packages gives it a certain
allure, and the arguments for and against it are both based on KISS principles.

We could also go the simple route and say that all packages that provide
libraries|modules for general use should include the prefix in the name, and if
they provide an application as well then they should "provide" the application
name in the PKGBUILD, i.e. the pkgname without the prefix in most if not all
cases.

Vice versa would work too, but the prefixed name subsumes the unprefixed name
and would thus result in a hit when searching for either, which I prefer.



Regards,
Xyne
 
Old 01-05-2011, 03:34 PM
Thomas S Hatch
 
Default Ocaml Packages

On Wed, Jan 5, 2011 at 4:32 AM, Xyne <xyne@archlinux.ca> wrote:

> Thomas S Hatch wrote:
>
> > Yes, this is an ongoing issue, and it starts to scrape the question of a
> lot
> > of package splitting with -devel packages. I think it would be safe in
> > saying that that in general Arch does not do -devel packages, and it
> would
> > be silly to start devel packages our here on the ocaml front!
> >
> > But this sounds good, I think I that finding some solid ground on this
> > little grey area will be the last part to the standard, I think I will
> ask
> > Richard Jones what he thinks (although he will give me some crap about
> arch
> > not splitting devel packages )
> >
> > -Tom
>
> I wasn't actually suggesting that we split the packages (whence the
> inclusion
> of "Perhaps the ideal..."). I was just considering whether there would be
> any
> advantages to that approach. The advent of split packages gives it a
> certain
> allure, and the arguments for and against it are both based on KISS
> principles.
>
> We could also go the simple route and say that all packages that provide
> libraries|modules for general use should include the prefix in the name,
> and if
> they provide an application as well then they should "provide" the
> application
> name in the PKGBUILD, i.e. the pkgname without the prefix in most if not
> all
> cases.
>
> Vice versa would work too, but the prefixed name subsumes the unprefixed
> name
> and would thus result in a hit when searching for either, which I prefer.
>
>
>
> Regards,
> Xyne
>

Heh, if anything I was speaking hypothetically, and yes the advent of split
packages does open up a barrage of packaging considerations. With all that
said, I think that you are spot on with your description, I will add it to
the wiki page later today.

-Tom
 

Thread Tools




All times are GMT. The time now is 02:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org