| Summary: | sys-block/tw_cli - please remove the supportedcards() thing from all ebuilds | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jakub Moc (RETIRED) <jakub> |
| Component: | New packages | Assignee: | Robin Johnson <robbat2> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | qa |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
'supportedcards' is called twice! I don't want to duplicate the information and bloat the ebuild. For a single einfo call, yes it should just be duplicated, but not for the quantity here. Yeah, it's called twice for no apparent reason; either the user found out that his card is unsupported in pkg_nofetch() and decided not to download the driver or found out that it is supported, downloaded the driver and then I fail to see why he is being told which cards are supported for the second time. if you already have the distfile (eg shared distfiles within a private network), pkg_nofetch doesn't run. (In reply to comment #3) > if you already have the distfile (eg shared distfiles within a private > network), pkg_nofetch doesn't run. OK, following this logic, all ebuilds in portage with RESTRICT="fetch" should be changed to display duplicate information both in pkg_nofetch() and again somewhere else. Back to the point - einfo is IMHO not the proper place to list hardware supported by en ebuild. Moving the list of supported cards to longdescription in metadata.xml and refering to that in ebuild's DESCRIPTION would be really a better solution, also because such information should be available to the user before he runs emerge. |
All the ebuilds contain something like this: <snip> supportedcards() { einfo "This binary supports the following units (the website is wrong):" ... (lot of einfo lines here) } pkg_setup() { supportedcards } Why are we inventing functions to call them from another functions, just to display plain einfo?! Reproducible: Always Steps to Reproduce: 1. Look at the ebuilds. 2. Ouch! Expected Results: Please, fix the coding, one user used this as an example for the ebuild he submitted. :/