| Index | index by Group | index by Distribution | index by Vendor | index by creation date | index by Name | Mirrors | Help |
The search service can find package by either name (apache), provides(webserver), absolute file names (/usr/bin/apache), binaries (gprof) or shared libraries (libXm.so.2) in standard path. It does not support multiple arguments yet...
The System and Arch are optional added filters, for example System could be "redhat", "redhat-7.2", "mandrake" or "gnome", Arch could be "i386" or "src", etc. depending on your system.
There can often be a tension between coding for flexibility and for future growth and writing code that is terse, to the point, and solves the smallest possible business problem that is brought to you. Writing the minimum code to solve a particular problem has merit, yet can eventually leave you with an application that has many hacky modifications and is hard to test in an isolated manner. Minimum code should not imply minimum forward planning or poorly tested code. For me, doing the right thing means I need to both limit myself to the smallest possible solution for a given business case, yet make sure I am not writing CODE that is impossible to grow over time in a clean manner. Generally I attempt to do this by clearly separating the problem domains under a business case into distinct classes. I then tie all the functional bits together in the loosest manner possible. the Moose manpage makes this easy, with its powerful attribute features, type coercions and Roles to augment classical inheritance. Loose coupling and deep configurability work well with inversion of control systems, like the Bread::Board manpage or the IOC built into the the Catalyst manpage MVC framework. It helps me to defer decisions to the proper authority and also makes it easier to test my logic, since pieces are easier to test independently.
Generated by rpm2html 1.6