Changing the "libs" recipes category

[jkloetzke]

When looking at BobBuildTool/basement-gnu-linux#106, I had the feeling that the "libs" category was probably not the best choice in hindsight. Changing it would create a lot of pointless churn, though. So I'm pondering to change the priority in the documentation so that the "libs" category would be "catch all" for generic C/C++ libraries.

In any case, I would be hesitant to move existing recipes.

[rhubert]

I think there are many recipes where the libs category doesn't mach very well. Especially for all these libs also providing tools. But if we change this now we might need a lib multiPackage to make things more clear? I also thing we need more categories than, otherwise many lib's simply would go to utils.

Taking botan as example, (security::botan?) I think something like

multiPackage:
  lib:
     multiPackage:
        dev: 
              [...]
        tgt: 
               [...]
  "":
      # tool...

would provide clear package names.

I'm also open in renaming the packages if there would be a (sed-)script which I can apply to my existing recipes.

[jkloetzke]

I also thing we need more categories than, otherwise many lib's simply would go to utils.

Right. As long as the categories do not intersect and there is a clear description, I'm all for adding new ones.

But if we change this now we might need a lib multiPackage to make things more clear?

That might be needed by some packages but not in general. If fact, many libraries have already "lib" in their name. So I would not make this a mandatory rule. Also, the -dev and -tgt suffix already imply that this is a library. I have to admit that this is a bit subtle, though.

I'm also open in renaming the packages if there would be a (sed-)script which I can apply to my existing recipes.

Ok. Sounds feasible. If we go this route then we should do it once and for all.