Re: build-depending on a virtual package
On Tue, May 02, 2006 at 07:14:21PM +0300, George Danchev wrote:
> On Tuesday 02 May 2006 13:42, Sven Luther wrote:
> > On Tue, May 02, 2006 at 12:14:30AM +0300, George Danchev wrote:
> > > Hello,
> > >
> > > I just discovered the fact that ara build-depends on a virtual package -
> > > ocaml-best-compilers. I'm not sure about the reasons we have been after
> > > to declared this in a such way, but this should give random failures
> > > imho. How are autobuilders supposed know which physical package(s) to
> > > install to satisfy the provision of ocaml-best-compilers. Seems it is far
> > > better to build-depend on ocaml-native-compilers or I'm missing something
> > > ?
> >
> > When, like in this case, there is only one real package providing the
> > virtual package, it is not really a virtual package we are facing, but more
> > an 'alias' of some kind.
>
> And that only real package is the only choice available for of autobilders to
> go for. If this is the case then it is completely deterministic ;-)
Indeed.
> > This problem has been known since 2000 or so, and the buildd coders have
> > never been interested in solving the issue.
>
> I'm not sure that the problem is not solvable presently ;-) I searched a
> little bit and saw in xfree86-4.3.0.dfsg.1 source package from stable that it
> is fine to put arch-dependant stuff in Build-Depends. For example we can have
> this:
>
> Build-Depends: ocaml-native-compilers [alpha amd64 arm hppa i386 kfreebsd-i386
> ia64 powerpc sparc], ocaml [ m68k mips mipsel powerpc s390 sh ]
Sure. The problem with this, is that we want this to be found in the package
providing the virtual package (ocaml), and not in gazillons of packages using
it. If a native compiler is later disabled or added, (as has been done
temporarily for ia64 when it was broken, or later for hppa), we don't want to
go modifying all those packages out there.
Notice that ocaml-best-compilers is just an optimization anyway, and all
packages should work just as well with just plain ocaml. It make sense to use
ocaml(c|opt).opt over the plain version only for huge packages like coq.
So, a dependency like :
ocaml-nox, ocaml-best-compilers
would probably be more suited.
> Even package (version) [ arch ] is recognized.
Sure, but this is hardly the point here :)
> Stefano, thanks for pointing the diff btw best and native compilers, I was
> quite sleepy yesterday night to guess what was exactly the case ;-)
>
> So, what do you think about setting Build-Depends this way ?
As above, i don't think it is a good idea, please also consider past
discussion about this in this mailing list.
> > Right now, this is solved by having the buildd admins set the dependency by
> > hand, it seems they are more interested in boring repetitive work than
> > working on the code base.
>
> Hm, strange. They used to use Packages-arch-specific filelist to prevent
> not-for-us build on sertain arches, but I'm not sure how these things are
> handled presently.
Manually.
> > This is in part because they don't come from a formal programming community
> > like the ocaml one, but are mostly perl hackers at the base, i believe.
>
> I'm also a moderate perl hacker ;-) But I also like strict languages like
> Objective Caml and Ada although I'm quite far from being fluent with them.
>
> > BTW, you do work on the EDOS project on dependency graphs and stuff like
> > that, right ? Do you have some insight on how this could be handled better
> > than it is done now ?
>
> I believe that it is Berke Durak and/or probably some other ocaml hackers
> behind the scene [1]. I'm not sure if they are related to any project at
> INRIA, but these guys are doing some really cool stuff.
Ah, yes, you are right, its Berke.
> > I guess that with debian stagnating in its tools,
> > other distribs (like mandrake) will clearly take the forefront in a few
> > years.
>
> Debian needs some good competitors to evolve I believe ;-)
>
> [1] I just have this information from the Ara's home page at:
> http://ara.alioth.debian.org/
> which is refering to http://ara.edos-project.org/
> which is refering to http://brion.inria.fr/anla/
Friendly,
Sven Luther
Reply to: