| 1 |
Miroslav Šulc wrote: |
| 2 |
> I've went through the Java resources several times. Here is what I found |
| 3 |
> about slotting: |
| 4 |
> |
| 5 |
> Slotting |
| 6 |
> |
| 7 |
> "Libraries should be slotted according to the API they provide. If two |
| 8 |
> version have the same API, or if a new version is fully compatible with |
| 9 |
> the previous version, then they should be in the same SLOT." |
| 10 |
> |
| 11 |
> I think it is not easy to determine whether an API changed a way that |
| 12 |
> would broke something. I think even knowing the package doesn't help the |
| 13 |
> dev. And documentation may not cover these changes. And using slot name |
| 14 |
> 3 when major version changes to 4 but there is still full compatibility |
| 15 |
> with version 3.x might be confusing. |
| 16 |
> |
| 17 |
Yep, not easy at all. One way would involve trying to compile |
| 18 |
everything, and make sure they don't break. Another is to use a tool |
| 19 |
used by the gnu-classpath to test source compatibility... the name |
| 20 |
escapes me at the moment though. One of our devs, betelgeuse, was |
| 21 |
working on automated scripts to test releases using said tool. |
| 22 |
> "Java libraries have a tendency to sometimes break API and ABI between |
| 23 |
> minor revisions, ie from 2.1.1 to 2.1.2. As a result, it is necessary to |
| 24 |
> slot early, and slot often." |
| 25 |
> |
| 26 |
> I went through /usr/share to see current practice. I can see most of the |
| 27 |
> Java libraries I have installed are not slotted at all (probably |
| 28 |
> SLOT="0") and in a contrary jdom is slotted on ${PV} so it comes I have |
| 29 |
> jdom-1.0_beta9 and jdom-1.0 installed. I code in Java for some time but |
| 30 |
> I don't use most of the Java libraries I have installed directly so I |
| 31 |
> just know they exist until something brokes and needs attention. |
| 32 |
> |
| 33 |
> |
| 34 |
> For example, I can see batik is slotted as 1.5.1 and 1.6. I don't use |
| 35 |
> this one but it's not obvious to me why it is slotted to 1.5.1 and not |
| 36 |
> just 1.5. How can one say this slotting is correct. Maybe it would be |
| 37 |
> good to have "slot reason" information in the ebuild too to be able to |
| 38 |
> make time efficient corrections and updates of the ebuilds. |
| 39 |
> |
| 40 |
Emphasis is on tendency, and sometimes... the API/ABI doesn't always |
| 41 |
break... so in those cases, it's fine not to use SLOTs. The reason for |
| 42 |
slotting is almost always due to API breakage for library packages. |
| 43 |
> "For applications, it is mostly sufficient to keep only the latest |
| 44 |
> version. If the application comes in series, such as Eclipse, we want to |
| 45 |
> keep the latest revision in each series. Very old series may eventually |
| 46 |
> be dropped completely." |
| 47 |
> |
| 48 |
> |
| 49 |
Eclipse is probably a special case now that I think of it. We like to |
| 50 |
package the milestones and RCs as they are released, but they're not |
| 51 |
always ready for primetime, or might not work with every plugin yet... |
| 52 |
so in this case, it's good to have the brand spanking new release |
| 53 |
installed next to the time tested one. |
| 54 |
|
| 55 |
-- |
| 56 |
Joshua Nichols |
| 57 |
Gentoo/Java - Project Lead |
| 58 |
-- |
| 59 |
gentoo-java@g.o mailing list |
Archives