On Wednesday, January 29, 2014 2:14 PM, Michael Schwendt <mschwendt(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging