Re: flag day for 64-bit?

[Marcus Brinkmann]

On Fri, Jun 07, 2002 at 10:39:33PM -0400, Roland McGrath wrote:
> Ok.  I wonder if there is some way we can make the dpkg dependency magic
> flag them for us

The glibc package can make packages compiled against it require this newer
(Debian) version, even if the soname stays the same.  But if you install
glibc+hurd but not foo-using-instable-rpcs, foo-using-instable-rpcs will
fail to run and we can't help it.

> Ideal would be something that prevented their installation.  But you could
> certainly just examine the extant package set for that dependency to be
> sure what to recompile (or even make the new hurd pkg conflict with those
> individual old pkgs?).

You would conflict foo-using-instable-rpcs (<= X.Y.Z), where X.Y.Z is the
last broken version.

> I simply accept that we won't have a usable netmsgserver
> before we have different IPC and IDL technology altogether and can address
> the whole question at a higher level.

Oh yeah, I buy into that.

> > This is then followed by a discussion about io_map, which we probably ignore
> > for now :)  unless we can agree on the right interface for it today.
> 
> I've already stated several times that we're agreed on my plan.

It must have gotten lost in the disagreement over the server side
implementationt, sorry.  I am touching this issue with long-distance pliers :)

> At least one of those times, Thomas said it would be acceptable.

I think I remember that, too (so it must be true).

> > If we can agree on that, we could probably get the interface change in here
> > for the future.  OTOH, changing the interface like this will require to
> > change the code a bit to meet the new semantics (and in fact, the client has
> > to do two RPCs if it wants a readable and a writable memory object - in case
> > they are disjoint).
> 
> I am not sure what you are saying here.  The only thing that makes sense
> (for mmap) is to say that the interface returns the max protection
> available and if that doesn't include what the client asked for, then mmap
> just fails.

Oh, mmmh, yeah ok.  The current interface confused me a bit.

> So, I tried a build with -D_FILE_OFFSET_BITS=64 and it went quite smoothly.
> So I now think that's the right thing to do.  The exported Hurd header
> files like store.h et al can be made LFS-aware so that they work in that
> mode and also in 32-bit mode with their interfaces using struct stat64 et al.

Sounds great!

Thanks,
Marcus 

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de