Re: new version of ocaml packages ...
On Thu, 27 Dec 2001 11:37:51 +0100
Stefano Zacchiroli <zack@debian.org> wrote:
> This works only because at the moment there are only a few ocaml
> related packages and most of them are libraries. Think bigger.
it will work in the large since the word O/caml appears somewhere
in the descriptions... which is very likely to happen I think.
> apt-cache search ocaml | grep libtk
apt-cache search caml | grep tk is enough
I prefer too much information (ocamltk, lablgtk, labltk) than
an empty result ...
> If you want to change the whole libxxx naming schema, go and ask on
> debian-devel.
Did I say something like that ?
We are speaking about a _future_ naming scheme...
I'm not concerned by perl stuff (and I hope that the reverse will be
true, i.e ocaml stuff should not be "polluted" by perl standards)
> If anyone builds its own packages following its personal whishes we
> could safely destroy the policy.
You are changing the topic of this discussion.
"I" cannot destroy a policy where there is none. As far as I know,
there is no agreement here to apply the perl/libXXX naming scheme,
> Why you think it is useless?
Explained in my previous mails.
> Its help in maintaining organized a
> very very very big slice of the debian archive.
don't you think that it is a very very very big slice _because_
someone decided one day to put libraries in the same tree ...
And NO, it didn't help ... if you look at the pool structure,
you will see 'lib-' (?????) then liba, libb , ... , and so on.
Do you really think it's a success ?
> Why you think that
> we should misc library packages with others?
to escape from the very very very big slice of the debian archive.
> Your simplest
> alphabetical order, if used with this schema, keep separated
> libraries from others, who cares if ocaml and python libraries are
> mixed? Not every user is a developer, so is better to
> libraries from non libraries than ocaml libraries from python ones
> (that are easy to separe: use grep!)
Sorry, but I can't understand why sorting following programs/libraries
is much better than sorting following, say, languages...
> The problem is that I can't see where your "new" is better than old
same as above but new <-> old ;-)
> one and even if I can see it the disomogeneity is probably a bigger
> problem that the one you are trying to solve.
I'm not trying to solve any problem since for now there are ocaml-*
names. You said that "libXXX" is good, I said the reverse. That's all.
> > Standards are also made to be improved.
> Only if there is a big advantage in doing so.
Perfectly right, but this is also true in the case we are
speaking about adopting a standard (where there is (quite) none),
as Sven sayed sometimes ago, there is no agreement on this here...
In the pas, It has happened here that I tried to convince someone _to
change_ the name of a (new) package, I didn't succeed (as far as I
remember). No problem.
Today, you're trying to convince us to change a few names to libXXX.
ok, why not!? But you'll have to convince the maintainers. Since I'm a
Debian(ocaml) user I have the rigth to explain why I disagree with
your proposal (** and I'm not trying to change the perl policy ** )...
After all, I'm not a maintainer so I'm not a real problem for you ;-)
PS : take a look at the ocaml-hump collection,
sorry the libhump-ocaml ... http://caml.inria.fr/hump.html
there are very few "libs" but much more "applications" with totally
different names, as you said **think bigger**, thus, only a few of
them will be catch in the libxxxx naming scheme...
Note again that, upstream, there is a (small) preference for names
like ocamlnet, ocamlre, ocamldap, ocamlmpi, ocamlpvm, ocamlcvs,
ocamlmake,
Strange isn'it ?
Now the question : what is our goal, not to disturb ex/perl users
brain policy, or not to disturb usual ocaml users switching from
unix/red-hat/win to Debian ?
--
mailto:georges.mariano@inrets.fr tel: (33) 03 20 43 84 06
INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59
BP 317 -- 59666 Villeneuve d'Ascq
http://www3.inrets.fr/estas/mariano
Reply to: