Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 12:23:41PM +0200, Matthias Urlichs wrote:
> Hi,
>
> Stefano Zacchiroli:
> > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote:
> > > I'd split the packages in three:
> > > - ocaml (arch-independent, common stuff)
> > > - ocaml-bytecode (ditto, bytecode interpreter)
> > > - ocaml-native (arch-dependent, compiles to native code)
> >
> > You miss the point: the ocaml package is already split properly, the
> > question arise for application builts with ocaml compilers.
> >
> Oh. *scratches head, re-reads initial email*
> I did not see that, given this email. Sorry.
Yes, my fault, i wanted to write it, but must have forgotten or
something.
> Anyway, the same three-way split technique can be used for any package
> using ocaml => take my email and s/ocaml/your-package/g.
>
> As for the user's choice ... I did miss the reference to apt-get in the
> original email, as I was mistakenly of the opinion that it would, like
> dselect, actually ask which dependent package to install if there's a
> choice. At the moment the manpage says that apt-get randomly selects a
> package which fulfills a virtual dependency. (That probably means "it uses
> the first one it sees in the package list". :-/ ) That shold be fixed; as
> .deb control files currently don't have a priority field, the first step
> would probably be to file a bug report^W^W feature request asking for its
> addition. Or do it yourself and submit a patch...
Yes, i guess that would be nice. Mmm, should i fill a bug report against
apt, or is there a better mailing list to discuss these things.
In case i submit a patch or something such, should i discuss things
first, or just go ahead and implement it ?
BTW, do you think apt-get (in its current incarnation) will choose a
true package in priority over a virtual one ? that is if i have foo and
bar (bar providing foo) and i do a apt-get install foo, will it choose
foo over bar, or select randomly ?
Alternatively, we could also have the both a foo_1.0-1_all.deb and a
foo_1.0-1_i386.deb (for example) in the archive, and have the per arch
PAckages file point to the native code one (foo_1.0-1_i386.deb) when it
is available, and to the byte code one (foo_1.0-1_all.deb) if it is not.
But then this will not allow an user to install the bytecode executable
unless he hand installs it.
Friendly,
Sven Luther
Reply to: