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

Re: some debs



> I compiled some packages for the hurd, here are the results:

Great!  Thanks for the help!  Are your packages available to get on the net?

> cnews_cr.g7-12:
> ---------------
> was including non-existent <sys/mount.h>. Also had to include
> <sys/statfs.h>, so that "struct statfs" could be found during
> compilation. I have made a diff, which I will send upstream if there are
> no objections (I am new to porting anything, should I send this to the
> debian maintainer of the packet, or the upstream maintainer ?). I could
> not install it anyway, since it depends on cron.  (see below)

I think there are other systems that have <sys/statfs.h> and that do not
have <sys/mount.h>.  If cnews uses autoconf or something like it, perhaps
it can check for those headers automatically.

> Misses the definition of MAXPATHLEN in <sys/param.h>. I have installed
> libc0.2-dev 2.1.1-12. Is there any packet I have missed to install or is
> there no such definition ? After defining MAXPATHLEN myself just for
> testing-purposes it compiled well...

The best thing is for (upstream) packages to change to using the POSIX.1
interface for this.  That, is use PATH_MAX if defined, else use
sysconf(_SC_PATH_MAX), and if that returns -1, then handle having no
determinable limit on file name sizes; that is what POSIX.1 requires an
application to do.  (On the Hurd, PATH_MAX is not defined and
sysconf(_SC_PATH_MAX) does indeed return -1, because there is in fact no
determinable limit.)  

If it is difficult to make those changes, or maintainers don't want to,
then it is a reasonable hack to just pick some limit instead of actually
coping with arbitrary-sized file names.  (There are many packages out there
that do this if neither PATH_MAX nor MAXPATHLEN is defined, rather than
using sysconf and handling a -1 return from it as POSIX.1 specifies.)  This
is of course not ideal, since it makes that program have an arbitrary limit
on the length of file names it can use, when there is no such limit in the
rest of the system.  On the other hand, since most (if not all) other
systems do have an arbitrarily limit (most often 1024 bytes), this does not
constrain using the program with any file names that you could use on Linux
or other systems.

Because <sys/param.h> exists for compatibility with old code, and old code
had a reasonable expectation of <sys/param.h> defining MAXPATHLEN, it might
make the most sense to have the Hurd's <sys/param.h> just define it with
some arbitrary limit.  POSIX-compliant programs will use PATH_MAX and/or
sysconf instead anyway.  We will have to think about this.


Reply to: