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

Re: -= PROPOSAL =- Release sarge with amd64



Stephen Frost <sfrost@snowman.net> writes:

> > No, if you do it right, then you can install the libraries with a
> > configuration variable, so that the packages only have to be changed
> > once, to use the variable, and when you change the directory, you can
> > do it in the right place.
> 
> Eh, you still have to go back through and change them all, and that's
> rather annoying, to say the least.

No, the point is that the library installs wherever the "install
libraries" configuration variable is set, and if you change the
variable, the library package doesn't have to be changed at all.  It
has to be reinstalled, and you can just do that automatically when the
variable gets changed.

> It will be beneficial to have the solution 'proved' to some extent
> before the LSB folks will want to commit to it..  We havn't really
> proven it yet (though there's nothing that's come up so far as a show
> stopper yet, and we don't expect any...).  It's my understanding that
> there has been talk with LSB and w/ RH and that they're open and
> interested in the idea.

By "prove" you mean "test", of course, and I'm all for that.  We test
things in sid, and if you want to put this in sid, I have no objection.

> Directory names and whatnot I would expect to be settled before we go
> through and change the entire archive for it...  

So would I.  So don't start now.

> If you expect a multi-arch spec, in any case, the issue of moving to
> the non-multiarch one and then to the multiarch one will exist.
> Regardless, really, the GR is about getting into sarge, and neither
> the non-multiarch /lib64 stuff nor the multiarch work would be ready
> any time soon for inclusion in sarge.

Then it isn't ready for sarge.  The more you patiently explain that a
good-looking solution isn't ready, the more convinced I become that
this belongs in sid, but not in sarge.

> I guess I have some foolish hope that maybe this is the only issue, and
> that we can settle it reasonably quickly.  

No, what is becoming clear to me (though I might be incorrect) is that
in general this isn't ready, mostly because it didn't live in sid, and
because suddenly at a late date people pop up and say "hey, we should
put this in sarge".  The way to get it into stable is to get it into
sid and testing.

To convince me to support a GR, you have to do more than just convince
me it's the right decision.  You have to convince me that the release
manager and technical committee are unable or unwilling to come up
with any workable solution.

It is *your* agenda to get amd64 into sarge, not mine.  *My* agenda is
to make sure stable is stable, and standard-conformant, and
well-tested.  If you want exceptions to two or three of those three
conditions, you have a very high hurdle if you want me to think that
the tech-ctte and RM should be overruled.

> Alright, if LSB compliance wasn't such a hurdle then why wasn't it done
> already?  

You can't tell me "it's a hurdle" and "it's not a hurdle" at the same
time.  

I don't much mind a pure64 system; it should be really easy to conform
to the LSB in this regard: "ln -s /lib64 /lib", and then presto-magico,
everything gets installed in lib64.

If that is really the only thing, then just do it.  Of course, it only
works on a pure64 system, but it does work, and works just fine, and
conforms to the standard.  

Thomas



Reply to: