[Fedora-packaging] Build Environment Consistency

[Gene]

On Wednesday, January 29, 2014 2:14 PM, Michael Schwendt <mschwendt at gmail.com> wrote:


> Not in your initial message. Apparently, you did assume that the reader of
> that message would click the link to github and read the extra text there.

I didn't assume they would click it; I asked them to and assumed that they wouldn't partake in a discussion unless they met the prerequisites which were clearly laid out.

Certainly a failure on my part by giving too much credit to people.


> Now that I've skimmed over the simple example on your github page, I still
> don't see the advantages. For example, with regard to maintaining the
> files in the "build root". It seems quite awkward to me to run something
> like "togo -f …" on each file or directory I want to include in a package.

Perhaps, but to me it's a lot easier to use the command line's auto-completion for paths rather than exit and re-enter my text editor multiple times to ensure I didn't make a typo in any of my paths included in the %file section.

Again, I stress that you may use the existing togo environment to generate a basic spec for you, which you may then tailor to your needs; building an RPM from your tailored spec rather than the generated one.

Togo just attempts to remove a lot of the leg-work that must be done for each revision of a package.


> If would be good if the documentation/examples covered package updates.

If you are talking about a change to the software that needs to be packaged, you may simply change it in it's place under the 'root' folder, then update your spec release/version/changelog and rebuild without doing anything else.

If there is something specific you'd like to see addressed, please let me know and I will see what I can do.


> What do you consider wrong with the %files lists in spec files?
> Even large %files lists in several sub-packages are convenient to
> maintain when using --short-circuit builds.

The %files list used to be an entirely automated list; it would simply include everything in your build root (back when directories could be owned by more than one package - something I believe should still be in place).

I believe that any package that drops a file into /etc, for example, retains partial ownership over that directory. You are, after all, performing installations as root; it's not a security vulnerability.

Upon removal, RPM used to leave any directory that was still occupied, and remove directories that were empty. I believe that system functioned just fine for directory handling and, of course, file ownership should still be one-to-one.

However, that was changed in the last few years and now packages that claim ownership of the same directory raise a conflict and RPM won't allow the installation to take place.

So, it was more of a conversion of how Togo used to do it than "something is wrong with %files, so I need to make a new system for it."

However, due to command line auto-completion of paths, I still like Togo's method more. Not only that, but for new users who may get confused with the paths (are they relative, or absolute? -is a common question), Togo's file handling functions as a tutorial.


> RPM supports "include files", so one could break a large spec file into
> pieces. Everything in one file is convenient, however, because if you perform
> a simple substitution (of a path or a macro name e.g.) you only need to
> touch a single file.

I agree with this, but spec files also confuse newcomers by containing and displaying information they don't need to worry about. Breaking them into their own sections allows new packages to focus on the options that they will deal with most.

Once a packager "out-grows" togo, they'll be making manual modifications to their spec-file as has always been done.


> It's common practise to adjust permissions in the %install section with
> chmod or "install -m …" or to use %attr in the %files section for special
> cases.


You specifically asked about ownership; something which must be done in the %post section on the remote machine so that UIDs are correct.

I have yet to add permission support to Togo, but it is on the roadmap and will be an expansion of the 'togo -f' feature. You'll simply set your permissions on your files as you would like to see them under the 'root' directory, and Togo will take care of modifying your %files list to match your build environment's specifications.

--
packaging mailing list
packaging at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging