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. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
