Let me take a quick guess here. The problem you are having is that the object names are case sensitive. The quick fix is to enclose the object names in double quotes, like this.
GRANT EXECUTE ON SYS."/1005bd30_LnkdConstant" TO mynewpublicrole;
You indicate that you "couldn't grant [EXECUTE ON] SYS./1005bd30_LnkdConstant" to a role.
I take that to mean that when you ran the GRANT statement, Oracle raised an exception, most likely,
ORA-00903: invalid table name
Enclosing the objectname in double quotes (as shown in the example) should fix that problem.
It's not possible to answer the question whether your new role needs EXECUTE privilege on those objects or not. Well, the role doesn't necessarily need them. The question is whether the user needs them or not (whether granted directly, or granted indirectly through roles.) That can be determined through thorough testing.
Some other comments.
If your intention is to create a new role and grant that role to all users, I don't see that security is changed or improved. So, I'm going to assume that is not the case.
It would appear you are trying to apply the principle of "least privilege". I applaud that effort.
One of the most common patterns I see application developers follow is to have the application connect to the database as the owner of the schema objects. What that means is that the application has all sorts of privileges it probably doesn't need, e.g. DROP TABLE, ALTER PROCEDURE, etc.
The pattern we use is to have an "OWNER" user that owns the schema objects, and a separate "APP" user that has specific privileges it needs on the "OWNER" objects, and synonyms for the "OWNER" objects. (The synonyms allow the OWNER.object to be referenced without being qualified with the OWNER.) It almost goes without saying, we do not grant privileges to PUBLIC, we grant to roles where needed.
I mention this because it's a pattern we use for implementing the principle of "least privilege".
For other security concerns, I recommend you review the "Oracle Security Checklist" white paper:
http://www.oracle.com/technology/deploy/security/database-security/pdf/twp_security_checklist_database.pdf
Some other possible exceptions you may have encountered when executing the GRANT statement:
ORA-01031: insufficient privileges
or
ORA-04042: procedure, function, package, or package body does not exist.
In either of those cases, make sure you connect to the database as SYS (SYSDBA) to grant the privileges. We almost always grant privileges as the owner of the object, rather than have some other user as the GRANTEE. I almost never use the "WITH GRANT OPTION" on object privileges. It's a simpler model, and avoids any potential problem with dependency trees.