You need to look at this from a different angle; based on your description, you are making software that supports the daily activities of the library employees (you are making it for them, to help them with their work). So, you are not modeling the library itself, but the business domain of the library. Primary actors are essentially people who interact with that system directly, in order to perform a business function within the domain you are modeling - e.g., perhaps the system enables them to do their daily work, or they are using the system because it provides some service for them.
In your case #2, the reader never interacts with the system (they interact with the librarian), so you could reasonably argue that, within the context of this model (and this particular use case), the reader is not an actor at at all (but an external detail you can mention in the description of the use case). The meaning of the use case isn't "reader borrows a book", but rather something like this: "a librarian enters check out information in order to let the reader borrow the book while keeping the catalog up-to date" (remember, the system is built to satisfy the business needs of the library; also, as a side note, I used the user story–style description here [role-what-why]). (Of course, maybe the library has a reader-facing portal that's part of your system, but that's a different situation, and a different use case).
So I would just treat the librarian as the primary actor. When modeling anything, you have to make a decision on where the boundary of the model is. E.g., if the reader is actually buying the book for someone else, is that someone else the initiator - and is it helpful to think about the problem in that way? Based on your question, you implicitly set the boundary to include the whole library as an entity, rather then just the system that you are building; that may feel natural, but it isn't necessarily useful from software development perspective.
A note on secondary actors. When following any practice or recommendation, try to figure out the reason behind it - it's not always easy to do that, but it's worth contemplating it. So, why do we make a distinction between primary and secondary actors in the first place? The idea is to identify the main business reasons for the existence of the system, the main functionality that it should have in order to satisfy the needs of the people for whom it is built, so that you can structure the system in terms of those main needs. This is about the "why" behind things - not for philosophical reasons, but in order to gather information that's relevant when building a system for someone.
Describing things in this way needs some practice, but it's important. To use the same example, a librarian doesn't want to access a specific screen to enter data about a book (this is missing the business-oriented "why"); instead, a librarian wants to enter check out information so that they could provide, in an organized way, a primary service the library offers (lets readers borrows books, keeps track of books). To figure these out, you will need to talk with people who work in your domain and who will be using the system (the domain experts). Understanding these let's you make the right architectural trade-offs (and there are always trade-offs), and come up with an initial architecture that supports the most important users and the most important functionality. I say "initial" because you still may need to tweak it as you learn more about the domain in the future, as you notice certain change patterns emerge, etc.
Secondary actors are supporting actors, in the sense that they exist to support the workflow of primary actors, but aren't in and of themselves drivers of the business value. Note that you don't have to come up with all these up front. Try to identify the primary actors, then revise the model as you go along, for as long as doing so is useful to you. Trying to get it all right up front is a very waterfall-y; in an agile setting, you have short iterations, and these let you learn, test assumptions, and remodel things over time as your understanding grows.