On Wed, 29 Jan 2014 09:16:00 -0800 (PST), Gene wrote:
> Yes, but it has been a lot of text without any examples.
The examples have been listed with real-world code.
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.
> How do you handle complex packages with scriptlets, triggers,
> long and custom %build and %install sections, %check sections,
> non-automatic inter-dependencies, a growing number of patches,
> directory ownership, subpackages? Just to mention a few cases.
> Where are the benefits over dist git plus fedpkg?
The simple answer is that I don't. You do. All I do is break up the spec file into a
more readable format.
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.
If would be good if the documentation/examples covered package updates.
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.
Your triggers and sections are all still there; all Togo does is
break
them into their own files so they're more readable.
If anything, my method works much better for long/custom sections because they are not in
the same file as several other long/custom sections.
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.
Permissions and ownership may be handled in your %post section, if
you wish.
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.