On Thu, 27 Dec 2001 11:37:51 +0100 Stefano Zacchiroli <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
