Reference Manual: RPM's Philosophy #3299
Conversation
ffesti
force-pushed
the
2897
branch
2 times, most recently
from
2efe3cf
to
255a8fa
Compare
|
Thanks a lot! Good to have a native speaker reading over this. Added the suggested changes. |
docs/manual/philosophy.md
Outdated
| --- | ||
| # RPM's Philosophy | ||
|
|
||
| The RPM package manager is a general purpose software manager. It |
There was a problem hiding this comment.
I think a brief definition of what that means would be in order here, something that covers the two sides of our operation: wrapping software into packages that the other side knows how to manipulate: install, update, remove, verify.
There was a problem hiding this comment.
I'd also place a bullet summary of the founding design principles right here in the beginning to set a frame of mind, roughly:
- general purpose software management
- building from pristine sources
- unattended operation
- reproducibility
- verifiability
What follows then expands on each principle.
docs/manual/philosophy.md
Outdated
|
|
||
| Package installation and update is unattended and must not require | ||
| user interaction. When possible delay user interaction to the first | ||
| start up. |
There was a problem hiding this comment.
Just drop the second sentence, user interaction is simply not an option during operation.
There was a problem hiding this comment.
Builds being unattended too doesn't seem to be mentioned anywhere, that's an equally important thing.
docs/manual/philosophy.md
Outdated
| Sources are given as files and patches. Upstream tarballs should be | ||
| used unchanged and patched during the build. This way packages can be | ||
| reviewed more easily and the changes made to the upstream project are | ||
| explicit. |
There was a problem hiding this comment.
In the rpm lore for this is called "pristine sources", I'd stick it somewhere in there 😅
There was a problem hiding this comment.
Also this is practically the same as "Separate Upstream Source from Patches" a couple of sections earlier. I get that there's a slight difference in perspective, but its quite repetitive. Backporting fixies too.
Maybe have a single "Pristine sources" section for the main beef, and elaborate on these things it enables as subsections?
docs/manual/philosophy.md
Outdated
| how software looks or gets packaged. Packaging software can be messy and | ||
| RPM accomodates for that. | ||
|
|
||
| It still offers help to create a POSIX like operation system. Marcos |
There was a problem hiding this comment.
Maybe "help in creating a ..."?
|
Lots of useful stuff here. I'd maybe move the Design goals as the first subsection so it goes from higher level towards details. Jumping straight into talking about macros seems like getting ahead of ourselves. Finally, these design goals appear to be missing entirely:
The reproducibility goal set in the nineties may not entirely match what folks these days use that term for, but it's an important goal nevertheless. Repeatability could be another term that can be used, if only to differentiate a bit from the current terminology. OTOH we are trying to support the current reproducibility initiatives too... |
|
Just realized this will make a nice addition to the contributing guide: when contributing / planning to, make sure the work aligns with rpm's link-to-design-philosophy. Doesn't have to be added in this very PR but wouldn't hurt either. |
|
Ok, I don't have the mental capacity to make this into a corner stone of western literature but it should now pass as a piece of our docs. |
|
Except for that one editing leftover mentioned above, looks fine to me. |
First brain dump.