On 01/30/2014 12:03 AM, Gene wrote:
On Wednesday, January 29, 2014 2:14 PM, Michael Schwendt <mschwendt@xxxxxxxxx> 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.
Not true. Rpm allows identical files and directories to be shared, older
rpm versions were buggy in that they did not require owner, group and
permission bits to match. The removal behavior depends solely on the
packages involved: owned directories are removed, unowned are not. That
behavior hasn't changed.
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.
Which would be just fine, but the togo workflow is likely to severely
alienate you from how packaging is *supposed* to work, because of the
way it mixes up buildroot contents, sources and file selection and such.
I'd kindly suggest you take a bit more time to familiarize yourself how
rpm packaging works as designed. Once you understand that, you'll find
what you seem to think as a some kind of a strange special case
(packaging binary-only software, home-made scripts etc) is no more
strange or difficult than anything else.
Only when *you* understand how it all fits together will you be in a
position to create an "educating helper" on top.
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.
No. File and directory ownership are specified with user- and groupname
in %files, and if the user/group is some package-specific thing, the
user/group need to be created in %pre of a package to allow rpm to set
the ownership as specified by the package.
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.
Well, permission bits can to some extent be specified on the directly on
the filesystem but ownership can not, as you must not assume (and should
not use) root for building packages.
- Panu -
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
