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

Re: hardinfo status.

On Wed, Sep 06, 2006 at 02:38:17PM -0300, Gustavo Franco wrote:
> >0.3.7pre-4, however, did build on alpha, arm, ia64, m68k and s390, and the
> >corresponding binaries are still in unstable. The maintainer has already
> >requested their removal (#385781) a few days ago, so it's currently waiting
> >for that to be actioned.

> In other words, the real status is that there are old binaries in
> architectures that aren't listed in hardinfo anymore and once #385781
> is closed, it will be able to move into testing, right?

It's correct that as long as 385781 is open, the package isn't going to
migrate into testing.

But as an alpha porter I object to 385781 being closed without there having
been any consultation of debian-alpha.  I don't see any reason that
architectures such as alpha, arm, and ia64 that clearly have the interfaces
hardinfo is intended to apply to should suddenly lose support for it as a
consequence of dubious upstream code abstractions.  I.e., the *only*
differences between any of the existing arch/linux/foo trees in this package
are in the processor.h file, which is itself unpleasantly non-headerlike,
consisting entirely of static function definitions.

I would probably be more than happy to write up processor_get_info() and
computer_get_processor() routines for alpha, but the additional busywork
imposed on porters by the poor overall code layout bothers me.  What could
have been a single build-time define and a C file with #ifdef'ed
architecture-specific routines is instead a symlink farm requiring manual
porting work just to get the package to recognize a new architecture
name(!).  Is this really an improvement over the portable code currently in
testing, for any architecture?

BTW, the sparc binaries are silently broken:

In file included from computer.c:70:
./arch/this/processor.h: In function 'computer_get_processor':
./arch/this/processor.h:44: warning: implicit declaration of function 'get_processor_strfamily'
mv -f computer.so modules


Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Reply to: