Miroslav Šulc wrote:
> I've went through the Java resources several times. Here is what I found
> 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 the
> 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.
>
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 to
> slot early, and slot often."
>
> I went through /usr/share to see current practice. I can see most of the
> Java libraries I have installed are not slotted at all (probably
> SLOT="0") and in a contrary jdom is slotted on ${PV} so it comes I have
> 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.
>
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 to
> keep the latest revision in each series. Very old series may eventually
> be dropped completely."
>
>
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.
--
Joshua Nichols
Gentoo/Java - Project Lead
--
gentoo-java-aBrp7R+bbdUdnm+yROfE0A@xxxxxxxxxxxxxxxx mailing list
|
