| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
I'd appreciate some ideas better than what I've come up with so far to |
| 5 |
deal with the very strange X.Org release naming. |
| 6 |
|
| 7 |
When modular tarballs are part of a full X.Org release (7.0, 7.1, etc), |
| 8 |
then they are named PN-PV-XORG_RELEASE.tar.(gz|bz2) and S matches. When |
| 9 |
modular tarballs are independently released outside a full X.Org |
| 10 |
release, they are named the standard way -- PN-PV.tar.(gz|bz2), same for S. |
| 11 |
|
| 12 |
Dealing with this all in an automated fashion in x-modular.eclass is |
| 13 |
somewhat difficult, and here's what I've come up with: |
| 14 |
|
| 15 |
A variable (XORG_PV), set by the ebuild, to tell _which_ release it's |
| 16 |
part of when it is part of a full release. If it's set, that means (1) |
| 17 |
it is part of a full release and (2) indicates which release it's part of. |
| 18 |
|
| 19 |
What does this mean for the future? All modular X ebuilds that are part |
| 20 |
of a full release will require XORG_PV to be set. All modular X ebuilds |
| 21 |
that aren't part of a full release will not require anything new. I'm |
| 22 |
doing it this way because I expect there to be more packages that aren't |
| 23 |
part of a full release than ones that are. |
| 24 |
|
| 25 |
Please give me your input on this. |
| 26 |
|
| 27 |
Thanks, |
| 28 |
Donnie |
| 29 |
-----BEGIN PGP SIGNATURE----- |
| 30 |
Version: GnuPG v1.4.2 (GNU/Linux) |
| 31 |
|
| 32 |
iD8DBQFDqjr2XVaO67S1rtsRAhlPAKCMvjj82U6sNPpVYsUOnKOsRwAF4QCgibKM |
| 33 |
Ccs1TnSQbXI66BVpf4P8Ed4= |
| 34 |
=NFr1 |
| 35 |
-----END PGP SIGNATURE----- |
| 36 |
-- |
| 37 |
gentoo-dev@g.o mailing list |
Archives