| 1 |
Hi! |
| 2 |
|
| 3 |
I've just committed new ebuilds for dev-java/istack-commons-runtime-1.0 |
| 4 |
and dev-java/istack-commons-tools-1.1 to java-experimental, based on the |
| 5 |
java-mvn-src eclass I committed along with it. Now I wonder how to deal |
| 6 |
with version numbers, as previous versions were based on CVS snapshots |
| 7 |
and had a date as their version number, i.e. 20070122 and similar. |
| 8 |
|
| 9 |
I can think of two possible solutions: |
| 10 |
|
| 11 |
|
| 12 |
1. Rename all 2007* ebuilds to 0.2007* in order to have 1.0 a higher |
| 13 |
version than these. |
| 14 |
|
| 15 |
Would require modification of all ebuilds that depend on a specific |
| 16 |
version of an istack-commons package. I found no such dependency in the |
| 17 |
main portage tree right now. In java-experimental there are two, for |
| 18 |
dev-java/jaxb{,-tools}-2.1.5. |
| 19 |
|
| 20 |
The ebuilds in the main portage tree would need to be renamed as well, |
| 21 |
which would probably cause recompilation due to downgrading for quite a |
| 22 |
few users out there. As the packages are rather small and build quickly, |
| 23 |
I see little point in trying to avoid these recompiles. Users in ~ARCH |
| 24 |
would probably directly upgrade to the 1.* releases in any case. |
| 25 |
|
| 26 |
|
| 27 |
2. package.mask the 2007* ebuilds. |
| 28 |
|
| 29 |
For this to work, the 1.* ebuilds would need to be stabilized fairly |
| 30 |
quickly, so that users can update to an unmasked version. The package |
| 31 |
itself is simple enough, but I guess the introduction of a new eclass |
| 32 |
would warrant some extended testing, especially using different java |
| 33 |
compilers, before stabilizing it. |
| 34 |
|
| 35 |
Ebuilds actually requiring an 1.* version of an istack-commons package |
| 36 |
would have to depend on ">=*-1.0 <*-20000000" or similar in order to |
| 37 |
express their actual dependency. For ebuilds like the jaxbe ones |
| 38 |
currently in java-experimental that would have to be even more |
| 39 |
complicated: "|| ( >= *-20070711 ( >= *-0.20070711 <*-20000000 ) )". |
| 40 |
|
| 41 |
|
| 42 |
I believe that the first solution would be the best one. I hope some |
| 43 |
developer with access to the main portage tree will implement this, |
| 44 |
either now or when istack-commons-* is about to hit the main portage tree. |
| 45 |
|
| 46 |
The second approach is useful for testing, and expressing dependencies |
| 47 |
in this way would help migration, as dependency information wouldn't |
| 48 |
have to be changed at the same time as ebuild names. |
| 49 |
|
| 50 |
Greetings, |
| 51 |
Martin von Gagern |
Archives