Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Project Proposals
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sven Luther <luther@l...>
Subject: Re: [Caml-list] OCaml packaging problems
On Fri, May 17, 2002 at 11:31:37PM +0400, Vitaly Lugovsky wrote:
> On Fri, 17 May 2002, Sven Luther wrote:
> 
> > >  In general, it's not a good idea to allow packages to modify 
> > > file (not claimed as 'configuration' file) belonging to the other package.
> > > It's an installation sequence problem (it's not specified when you're
> > > installing a lot of packages in one time), it's a security problem
> > > (some may want to have a partical ownership/rights for such a file,
> > > which will be broken by that %post and %preun scripts). And, at last,
> > > it's not a modular approach. It's not a good idea to mix a configuration
> > > and a cache.
> > 
> > Mmm, will look into it, so you are saying to me that there could be
> > problem when multiple users are running ocaml-ldconf at the same time ? 
> 
>  No. First problem is that package could be installed BEFORE the package

This should not be hapenning, it probably is a bug in your package
handler. Not sure though.

What can happen is that both package are installed first, and then only
configured, altough this late one will probably still be done in the
dependency order.

> it depends on, and, so, the file will not be updated. I don't know
> is it apt-rpm bug or a general rpm feature, but I've noticed this behavior
> a few times. And another one problem is that update script must be started
> by the configuration file owner, which is a potential security hole.

Well, it mostly is run by root, and so i guess this is a problem when
you don't trust the packager. This is where debian's large web of truce
and big number of packaged programs help a lot :)))

> > I don't really think that is so, but i will look more into it.
> 
>  And, sure, there could be some problems with blocking. But I did not
> considered this yet.

Mmm, ...

> > 1) for package installs, dpkg ensures that only one dpkg is running at
> > any time and that there is only one package being configured at the same
> > time.
> 
>  And the same for rpm. But we may have a local packages as well, installed
> without packaging system. It's a pain with only one global configuration
> file.

Well, not really, since upto now, they were handled in a separate file
(/etc/ocaml/ld.conf) and even if you install them at the same time as
you upgrade the system, it will only be broken until you next upgrade
an ocaml package (and even then, its your own fault for messing things
up).
> 
> > 2) you need to be root to run ocaml-ldconf, so i think, security wise,
> > there are a lot more thing to worry about if it is not you that have
> > control on things, and if you do, i suppose you would not install two
> > libraries at the same time ?
> 
>  Sure. But we have only one configuration file, not a list of files with
> different permissions and priorities. And so, localy installed libraries

Mmm, we have two for debian, /etc/ocaml/ld.conf for the locally
installed files, and /var/lib/ocaml/ld.conf for the dpkg handled ones.
The first one will never be touched by ocmal-ldconf, and so there is no
big risk about it.

The only problem i have right now, is that locally installed files want
to write to /usr/lib/ocaml/ld.conf, which is overwritten by a next run
to ocaml-ldconf, i will be changing this in the next release of an ocaml
debian package. There are two ways of doing this, making
/usr/lib/ocaml/ld.conf readonly, so people running local installs will
read it, and patching ocaml so it uses a /usr/lib/ocaml/debina_ld.conf
or something such, and have /usr/lib/ocaml/ld.conf be a symlink to
/etc/ocaml/ld.conf (which is a much more appropriate choice for this
kind of thing, and policy compliant to boost. It would be nice if ocaml
3.05 would allow an easy configuration of the position of this file, as
well as a option to ocaml that give this path back, in order for install
systems to cope with non standard places.

> goes there as well. And, again, we must install the package owning that
> configuration file while we only want to use some applications and runtime
> libraries used by them, which is not a good approach.

Yes, maybe it would be ok to consider ta ~/.ocaml/ld.conf file ?

> > But then, maybe i am not understanding you right, or you are speaking
> > about a user modifiable config file ?
> 
>  Since we have only one config file, without local and per-user modules,

Yes, i understand, we have two, so the problem is not so big, altough
there are other problems, like the ones mentioned above, and the fact
that you have to run ocaml-ldconf after modifying the local ld.conf
databas (like it is done for the C /etc/ld.conf). If ocaml-ldconf was
part of the upstream ocaml, it would make things easier.

> this one should be user-modifiable. Or we have to invent a more modular
> and secure approach. As well as I'm dreaming about having alternative
> locations of texmf tree with their own ls-R configs.

Mmm, my understanding was that users should use some other kind of trick
for playing with dlls, not the ld.conf ones, especially if he is not
root, unless it is a local ocaml install that is.

> > >  Sure. But distribution packagers, like me, can't wait for
> > > such a decision. :(
> > 
> > Well, not sure, we decided on a course back then in january, and
> > implemented it, now it turns out that we should have taken a different
> > approach (since Xavier suggests it).
> > 
> > Ideally there would be a strong policy document on such things.
> 
>  Sure. But this policy must be secure and flexible enough not to conflict
> with partial distributions policies.

huh ???

What parital distributions policies are you speaking about ?

> > >  And, one more thing we have to keep in mind:
> > > it will be very nice to have a possibility to split ocaml libraries
> > > into runtime and development parts. Dynamic libraries belongs to the
> > 
> > Ok, we have done that for debian, there is a libzip-ocaml package for
> > example, that contains only the dll, and there is a libzip-ocaml-dev
> > package that contains the rest of it, provides camlzip for backward
> > compatibility  and is built from the same source.
> > 
> > No major problem here (apart from a long flamewart on the choosing of
> > the name scheme).
> 
>  May be there's no problem, but how do you handle dll paths without
> that config file belonging to ocaml package? I can't check out Debian

There is a ocaml-base package, which has only the dlls of the ocaml core
distribution, the ld.conf files (mmm, maybe not even them) and the
ocaml-ldconf executable.

Each ocaml related package which has dlls is calling at postinst and
prerm the ocaml-ldconf file, which adds or removes a path/package line
in the /var/lib/ocaml/ld.conf file, and then regenerates the
/usr/lib/ocaml/ld.conf file from this file and the /etc/ocaml/ld.conf
one.

If one of these files does not exist yet, they get created by the
ocaml-ldconf program. I don't remember out of hand, but i guess they are
also marked as conffiles, at least the /etc/ocaml/ld.conf one is.

> approach now due to the problems with internet connection :(

:)))

> 
> > > runtime part, and, then,  should be handled in an OS native way.
> > > For Unices it's a libraries located in one big pile like /usr/lib/
> > 
> > Not sure if this zould be the real solution, since the dlls are handled
> > in a something different way than normal unix C libs. (well in the way
> > ocamlc and ocamlrun uses them maybe ?)
> 
>  I can't see the difference. Can you explain it?

Well, they are only used by ocamlrun and ocamlc and co, not by any
external program.

> 
> > >  But this way is native for unices. It's generally used when you have
> > > different versions of libraries, and so on (see GNU libtool naming
> > > scheme for example).
> > 
> > Ocaml doesbn't support versioning anyway, and there is no real need for
> > it.
> 
>  As well as C. Version is just a part of the library name. So, we can
> have different versions of the library in the same directory, with
> different applications linked with all that versions without conflicts.
> It's not a language-specific matter at all.

Well, previous discution here had me convinced that versioning would
involve non trivial type checking for incompatible module interfaces or
something such (not the best explanation, so please look at that huge
thread youself).

The basic idea was that if you were going to do versioning, let's do it
right, and not like it is done in C, and that doing it right is not an
easy thing.

> > And even if it is used, it can cause also a lot of trouble, so if you
> > don't need it, better avoid it.
> 
>  It can't cause troubles. But the lack of this feature can. Don't you

Sure, just imagine someone changes the interface without bumping the
major version number, or that some of the symlinks got broken badly by a
mix of hand and automated isntalls (not to speak about a broken
package), and things will break some, don't you think.

> remember all that Windows pain with DLLs?

No, i never run windows if i can avoid it :)))

> > BTW, what distribution do you represent and how many ocaml packages and
> > libs do you maintain ?
> 
>  ALT Linux. It's a russian distribution formerly based on Mandrake, but

Ok, i didn't know of you. Please feel free to subscribe to the
debian-ocaml-maint mailing list, where we discuss things related to
package maintenance of ocaml related packages. It is debian specific,
but many things may not be, and i think we will be happy to have you
there (well as the list moderator, i am inviting and welcoming you).

> evolved then to the completely new base. It's working over apt-rpm port.
> Now I packaged some findlib-based libs, lablGL, lablgtk, camlimages,
> camltk, and so on - the things I'm using myself. And I can't move forward

Same for me, (altough i don't do findlib myself, i never use it). BTW,
did you resolve the problem of camltk not being dll ready ?

> until the clear library packaging approach is choosed. :(

Well, ok, i see your point. We decided to choose a solution that worked
ok for us, and i did implement it. Now, it appears upstream as choosen
another approach, but debian woody will chip (any day now) with the
current situation of using two databases and ocaml-ldconf.

Friendly,

Sven Luther
> 
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners