On Sat, Feb 25, 2012 at 09:30:27PM -0600, Ted Gould wrote: > On Sat, 2012-02-25 at 14:51 -0500, Scott Kitterman wrote: > > On Saturday, February 25, 2012 01:42:51 PM Ted Gould wrote: > > > Hmm, my understanding was that it was something in the Ubuntu policies > > > and procedures. I think it does effect things like derivatives, no? > > > Anyone on the RT can approve MIRs, right?
> > No, there's a separate MIR approval team for that. After Precise none of > > the > > other flavors will be in Main, so it won't matter. For Precise and earlier > > Kubuntu would be affected, but it's status is changing, so it's only > > Ubuntu/Ubuntu Server that are at issue. > Oh, okay, I didn't realize. Do you then think that any potential policy > should avoid talking about main and MIRs or it's just a "don't care"? I think it's a grave mistake to try to dictate such a policy *except* in the context of main. First, most of the packages in universe are ones that we get for free from Debian. They require almost no upkeep and are almost never modified, but provide value to our users by increasing the amount of free software available by default on Ubuntu. Requiring this software to be ported to the toolkits and technologies that are on the roadmap for the default Ubuntu install would simply result in a lot of this software being removed from the release, making Ubuntu less useful *and* costing the archive admins a huge amount of effort to filter our Debian syncs to comply with such a policy. Second, Ubuntu is a cosmopolitan community, and there are several recognized community flavors which for one reason or another have made different technology choices than we make for Ubuntu (the images). These flavors should continue to have the freedom to make these different choices *within* the framework of the Ubuntu archive, and not have the choice taken from them, or the timeline dictated to them, based on the technology decisions that have been made for main. So while we could recommend particular technologies, it would be counterproductive to mandate them for universe. And we're already tacitly recommending technologies by virtue of what we choose to include in the default install. For main, I certainly think it's an interesting idea to have this sort of deprecation roadmap. (And I don't agree with Scott that this would be a Canonical-internal thing; while Canonical has some say in whether a package can be in main because packages in main have to be supportable by the security team, there are plenty of cases where particular software has been nominated for main by other members of the community.) I'm not too sure about the mechanics though - is this really something we want to ask the MIR team to have to keep track of? They're stretched thin as it is. > I think that there ends up a couple of classes of software, that which > is well maintained and that which is maintained on life support. Where > it still exists and works, but it's not being kept up-to-date with all > the recent changes in how a modern distro works. This is defining a way > to start removing things from the archives that are in that second > category. Again, this would be a huge increase in archive management costs for no real benefit. > Well, to be fully LSB compliant we'd have to switch to RPM as well ;-) No, that's not what LSB means <grr>. An LSB-compliant distribution only has to support installing packages in the subset of the RPM format specified in the LSB. > I don't believe that LSB is a requirement that we've made for Ubuntu, > but I can't find anything on that with a Google search. Again, if that > is a requirement the specific transitions here could be modified to take > into account those requirements. The LSB certification process has always been dysfunctional, expecting distro vendors and OEMs to both pay for certification and thus utterly failing to ever achieve a critical mass of either. Debian and Ubuntu have both had an lsb support package available for years that depends on the corresponding system libraries and allow for installation of LSB packages by way of 'alien' rpm->dpkg conversion. I gather there are some printer driver packages out there that make use of this, and I guess they work well enough today. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
