Ignacio Vazquez-Abrams wrote:
On Tue, 2005-08-23 at 09:48 -0500, Tommy Reynolds wrote:
>Uttered Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>, spake thus:
>>Attached is an outline for a guide to building packages under Fedora, in
>>notecase format (available in Fedora Extras).
>Thank you for participating in the Docs project. I would rather your
>outline be an ordinary text file, HTML, OpenOffice, or PDF file and
>be readible using anything from the basic Fedora distribution.
>Nothing wrong with the Extras tools, but requiring folks to download
>a non-standard package to read the outline seems to be a awkward start.
Okay, I went ahead and removed the NoteCase header and renamed the
extension, and ran it through HTML tidy for good measure.
2005.08.22: 0.0: Initial proposal (Ignacio Vazquez-Abrams)
RPM (RPM Package Manager) is at the heart of Fedora Core. It's responsible for
installing new software, as well as tracking files so that the same software can be
uninstalled with a minimum of fuss. But RPM on its own doesn't actually do anything.
It's up to the packager to specify how a package is built, as well as explaining what
sort of files the package contains, and what other packages it relies upon for proper
Structure of a package
This contains things such as the name, version, release, epoch, and architecture the
package was built for, as well as what this package requires from other packages and what
it provides to other packages.
This contains all files, directories, symlinks, etc. contained in the package, as well as
the size, permissions, ownership, and SELinux file context.
This contains the scripts to be done on package install and uninstall, as well as the
script done during a RPM verify.
Modifying an existing package
(go through the various reasons why one would want to modify an existing package)
Case Study: PHP
(modify the PHP package for adding <capability>)
What kind of capabality are you documenting here?. can you clarify that
Creating a new package
(reiterate RPM's file tracking capabilities vs. tarballs)
Case Study: (TBD)
(go through building a new package for (TBD))
Appendix: mock: Chroot Buildtool
(description of what a chroot is)
(description of mock's command-line arguments)
(description of mock's config file structure)
Appendix: plague: Distributed Buildsystem
(description of what "distributed" means, as well as plague's cross-platform
(description of how to configure plague-builder and -server)
(description of how to use plague-client)
Rest of the guide looks good to get started with and better
documentation about building packages and on plague is something thats