From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1G6qFD-0007qY-Lp for garchives@archives.gentoo.org; Sat, 29 Jul 2006 14:56:48 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k6TEtZQs020704; Sat, 29 Jul 2006 14:55:35 GMT Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k6TEtYw3007709 for ; Sat, 29 Jul 2006 14:55:35 GMT Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 29 Jul 2006 10:55:38 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id LYO92799; Sat, 29 Jul 2006 10:55:33 -0400 (EDT) Received: from 146-115-26-214.c3-0.abr-ubr1.sbo-abr.ma.cable.rcn.com (HELO [192.168.1.6]) ([146.115.26.214]) by smtp01.lnh.mail.rcn.net with ESMTP; 29 Jul 2006 10:55:32 -0400 X-IronPort-AV: i="4.07,194,1151899200"; d="scan'208"; a="245929097:sNHT30073254" Message-ID: <44CB76AA.9060403@gentoo.org> Date: Sat, 29 Jul 2006 10:54:34 -0400 From: Joshua Nichols User-Agent: Thunderbird 1.5.0.4 (X11/20060702) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 To: =?windows-1252?Q?Miroslav_=8Aulc?= CC: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] Gentoo/Java staffing needs References: <44C7D4AE.20306@gentoo.org> <44C9D289.6000001@startnet.cz> <44CAE067.5030104@gentoo.org> <44CB3FAB.4030103@startnet.cz> In-Reply-To: <44CB3FAB.4030103@startnet.cz> Content-Type: text/plain; charset=windows-1252 X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.44CB7692.0004,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.4/2006-05-04 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k6TEtZRK020704 X-Archives-Salt: ea288cdd-9fab-4693-9335-afec5247b23b X-Archives-Hash: c64e18ecf724dae957693f600acaf8fe Miroslav =8Aulc wrote: > I've went through the Java resources several times. Here is what I foun= d > about slotting: > > Slotting > > "Libraries should be slotted according to the API they provide. If two > version have the same API, or if a new version is fully compatible with > the previous version, then they should be in the same SLOT." > > I think it is not easy to determine whether an API changed a way that > would broke something. I think even knowing the package doesn't help th= e > dev. And documentation may not cover these changes. And using slot name > 3 when major version changes to 4 but there is still full compatibility > with version 3.x might be confusing. > =20 Yep, not easy at all. One way would involve trying to compile everything, and make sure they don't break. Another is to use a tool used by the gnu-classpath to test source compatibility... the name escapes me at the moment though. One of our devs, betelgeuse, was working on automated scripts to test releases using said tool. > "Java libraries have a tendency to sometimes break API and ABI between > minor revisions, ie from 2.1.1 to 2.1.2. As a result, it is necessary t= o > slot early, and slot often." > > I went through /usr/share to see current practice. I can see most of th= e > Java libraries I have installed are not slotted at all (probably > SLOT=3D"0") and in a contrary jdom is slotted on ${PV} so it comes I ha= ve > jdom-1.0_beta9 and jdom-1.0 installed. I code in Java for some time but > I don't use most of the Java libraries I have installed directly so I > just know they exist until something brokes and needs attention. > > > For example, I can see batik is slotted as 1.5.1 and 1.6. I don't use > this one but it's not obvious to me why it is slotted to 1.5.1 and not > just 1.5. How can one say this slotting is correct. Maybe it would be > good to have "slot reason" information in the ebuild too to be able to > make time efficient corrections and updates of the ebuilds. > =20 Emphasis is on tendency, and sometimes... the API/ABI doesn't always break... so in those cases, it's fine not to use SLOTs. The reason for slotting is almost always due to API breakage for library packages. > "For applications, it is mostly sufficient to keep only the latest > version. If the application comes in series, such as Eclipse, we want t= o > keep the latest revision in each series. Very old series may eventually > be dropped completely." > > =20 Eclipse is probably a special case now that I think of it. We like to package the milestones and RCs as they are released, but they're not always ready for primetime, or might not work with every plugin yet... so in this case, it's good to have the brand spanking new release installed next to the time tested one. --=20 Joshua Nichols Gentoo/Java - Project Lead --=20 gentoo-java@gentoo.org mailing list