[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian GNU [was: smarter way to differ architectures needed?]



>>>>> Timothy Baldwin writes:

 TB> I suggest that hwarch-foo can only be installed on hardware foo
 TB> and provides hwiset-bar for each instruction (sub-)set foo
 TB> provides.

It would be easier to call `hwiset-*' simply `cpu-*'.

In fact, that is the conclusion that Marcus Brinkmann led me to, and
so it will be in my policy proposal.

A lot of the complexity you are talking about is premature.  Let's not
worry about this until we have some real-world examples, and not just
`foo' and `bar' to talk about.

I think that my proposal is sufficiently general so that it won't
block progress on these kinds of issues, which is the most that we can
ask for without going into a lot of detail.

 TB> Currently we have libraries which share the same soname, but are
 TB> binary incompatible (as they have been compiled for different
 TB> architectures), this could be solved by putting a identifier for
 TB> the binary interface in the soname or put them in different
 TB> directories. It is also possible that in the future ld.so takes
 TB> care of instruction set dependencies.  User-Agent:
 TB> POPstar/2.01b11

You have hit the nail on the head.  This is the eventual goal, and
will be the solution to the huge libtool flamewar that we had on
debian-devel a while ago.

It will also make things like the libc5->libc6 upgrade a heckuva lot
easier.

 TB> This solution solves most problems of the solution currently
 TB> being discussed, except that does not cater for SMP systems
 TB> [with] dis-similar processors.

That's a *slightly* harder problem than I seek to solve with my
initial proposal. ;)


 >> >I think that an essential required base package should Provide
 >> >default hwarch.  Maybe that package should be `base-files'?
 >> 
 >> I think base-files currently has architecture set to "all"...
 >> 
 >> Anyway, I personally would prefer to keep them seperate.

 TB> Especially as they could be very hardware dependant.

Exactly.  And so, I'm in the process of designing an experimental
`hwarch' package which encapsulates all the Provides that the package
system needs to know about the physical machine.

Thanks for your comments: they definitely explore my ideas to their
logical conclusion.

-- 
 Gordon Matzigkeit <gord@fig.org>  //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)


Reply to: