| 1 |
Ok, this thread may be a waste of time but still... |
| 2 |
|
| 3 |
Portage could "taint" packages that is installed with unsupported or |
| 4 |
tainted packages as dependencies. Have portage give a warning about |
| 5 |
tainted packages. |
| 6 |
|
| 7 |
This way a user could easily resolve these kind of problem without |
| 8 |
submiting a bugreport. |
| 9 |
|
| 10 |
This paricular kind of issue is verry common on my machine, and the main |
| 11 |
reason I DON'T submit bugreports. |
| 12 |
|
| 13 |
Just a ~x86 package here and there and strange errors emerge. |
| 14 |
|
| 15 |
/John |
| 16 |
|
| 17 |
On Thu, 2004-01-22 at 21:58, Spider wrote: |
| 18 |
> begin quote |
| 19 |
> On Thu, 22 Jan 2004 18:34:05 +0100 |
| 20 |
> John Nilsson <john@×××××××.nu> wrote: |
| 21 |
> |
| 22 |
> > I do belive that the issue tracking system is flawed if these kind of |
| 23 |
> > bug-reports is a problem though... |
| 24 |
> > If all bugs was attached to a specific ebuild, this wouldn't be |
| 25 |
> > problem would it? |
| 26 |
> |
| 27 |
> |
| 28 |
> *cough* |
| 29 |
> |
| 30 |
> No. It would be an even worse problem. |
| 31 |
> |
| 32 |
> take a bug like this : |
| 33 |
> http://bugs.gentoo.org/show_bug.cgi?id=38835 |
| 34 |
> |
| 35 |
> in this case it was simple to detect, just for me to check out the |
| 36 |
> latest tree, scan versions and compare to information given. |
| 37 |
> |
| 38 |
> However, as seen here, its not an easy thing for users to know what |
| 39 |
> causes a problem, if it is a library subdependency or something else. |
| 40 |
> This is even worse when some testing library breaks interfaces, and then |
| 41 |
> they install it, together with the updated development set that matches, |
| 42 |
> and then -downgrade- again, however, parts are still linking to the old |
| 43 |
> one, using the new interface, that one is rebuilt afterwards, and you |
| 44 |
> are left with library mismatch and symbol relocation errors because of |
| 45 |
> the changing interfaces. |
| 46 |
> |
| 47 |
> Yes, I've tried to debug such cases for users, who technically are |
| 48 |
> correct, they don't have any "development" stuff installed anymore. |
| 49 |
> That doesn't matter, their system is still borked when it comes to that |
| 50 |
> library and all things inheriting. Causing developers a real pain. |
| 51 |
> |
| 52 |
> |
| 53 |
> So, attaching all bugs to the single place of failure wíll obscure |
| 54 |
> matters even worse. inviting people to a testing/bleeding edge tree |
| 55 |
> managed by users will give us a severe headache. |
| 56 |
> |
| 57 |
> |
| 58 |
> //Spider |
Archives