| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Mike Frysinger wrote: |
| 5 |
> On Wednesday 07 June 2006 11:13, Brian Harring wrote: |
| 6 |
>> 1) requires modifying the tree, and introduction of eclass for it. |
| 7 |
> |
| 8 |
> this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do |
| 9 |
> not want to go through every single package i maintain and add 'debug-build' |
| 10 |
> to IUSE or 'inherit some-new-eclass' |
| 11 |
|
| 12 |
Sometimes it takes a little extra work to do things right, but hopefully it will pay off in the long run. A poor design decision made now can haunt us for years to come. |
| 13 |
|
| 14 |
> if the large majority of packages are going to be taking advantage of a |
| 15 |
> feature, isnt the logical thing to opt everyone in rather than forcing the |
| 16 |
> majority to opt themselves in ? |
| 17 |
|
| 18 |
It really depends on the pros/cons applying something on a *global* scale, like you propose. A package manager (such as portage) will never be able to make debug-build decisions that work well for *every* ebuild. That's why it's better for ebuilds to make those decisions themselves (with the help of eclasses). |
| 19 |
|
| 20 |
Sure, it will take some work to make those changes to ebuilds, but it will be worth the effort in the long run. I've attached a script that you can use for /etc/portage/bashrc that provides the same functionality as your debug-build feature. You can use it as an interim solution until USE=debug-build support has been added to all of the ebuilds that would benefit from it. |
| 21 |
|
| 22 |
Zac |
| 23 |
-----BEGIN PGP SIGNATURE----- |
| 24 |
Version: GnuPG v1.4.3 (GNU/Linux) |
| 25 |
|
| 26 |
iD8DBQFEhxtN/ejvha5XGaMRAlRuAJ0Q0/p6Tq1k/+N3ejzScYsAe8TgvgCg3Wym |
| 27 |
EpgniVng6MItb8uxtJLk5Ac= |
| 28 |
=2nT/ |
| 29 |
-----END PGP SIGNATURE----- |
Archives