On Mon, Jun 27, 2005 at 02:00:16AM -0700, Matt Taggart wrote: > Andreas Barth writes... > > I think we should start to discuss which LSB version we want to have as > > basis for etch soon. > I don't know of any reason why it can't be LSB 3.0 (spec release this week). > It does require a newer glibc than sarge and some of the X tests might require > Xorg to pass, but those are both goals for etch right? I'll be running the 3.0 > tests on etch soon. > > about LSB, you can of course lead that discussion if you want. In any > > case, we would be thankful for your input on this matter, especially on > > a list of differences between LSB 1.3 (which is still the standard in > > Debian), and the best-match for etch in your opinion. > I think we might even been 2.0 compliant in sarge, but we're still testing > that. Jeff Licquia is certainly of the belief that sarge is not 2.0 compliant, but I haven't seen any specifics on this. I gather <http://lists.debian.org/debian-lsb/2005/06/msg00012.html> comprises the results of a number of the tests for sarge, but I'm not tracking LSB closely enough to appreciate the significance of the specific failures without a lot of digging. > > Feel free to start a public discussion by posting these information > > directly to debian-devel, or to hand them over to the release team or to > > me, so that we can start a public discussion, or in anything else as you > > consider it fit. > Ok, good idea, I'll bring the subject up on debian-lsb and maybe send a > pointer or summary to debian-devel for those not on debian-lsb. Looks like there's been a discussion about doing stuff for LSB 3.0 support, but no discussion yet about whether it's sensible and appropriate to target LSB 3.0 for etch? > > If there is anything else from your side on that matter, please don't > > hesitate to tell us. > OK. > How do you feel about multi-arch? > http://people.debian.org/~taggart/multiarch/ I'm definitely in favor of multiarch as a long-term strategy. Some members of the ftp team seem to be less convinced. For etch, it would be nice to at least have the groundwork laid, where we have a standard that says where the runtime linker should be for each architecture, provide a linker in that location as well as in the current location, and update the toolchain so that binaries are built with support for the multiarch linker path; I think that the set of packages we should actually support *installing* in a multiarch configuration for etch is rather minimal. But in any case, standardization seems to still be the first step? > How do you feel about support for alternate (ie non-sysv) init systems? I've encouraged Lars Wirzenius's interest in pursuing a dependency-based init system for etch. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature