On Wed, 29 Jan 2014 14:03:34 -0800 (PST), Gene wrote:
> 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.
>
It's certainly not necessary to exit an editor while working on a spec file.
It's possible to trigger builds (or short-circuit builds) from within a
second terminal (or after Ctrl-Z) or with built-in RPM features such as
available in Emacs.
And, of course, rpmbuild prints the list of files found in the %buildroot
in a way you can copy it into a %files list, provided that you believe it
to be a good idea. For large packages that would be less than ideal,
however, because typically the packager would include specific directory
trees or use wildcards to include more than a single file per line.
> > 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.
>
How would that be easier (or superior) than updating a single .spec file?
And what about updating the %files lists? In your examples you talk about
marking files/dirs in the "build root" with "togo -f …". What happens in
the case of package upgrades? How are sub-packages handled?
> If there is something specific you'd like to see addressed, please let me know and I will see what I can do.
>
I had hoped it would become possible to get to know the work-flow (based
on reading documentation and examples) without having to give the tool
a try.
How do you insert into the %files lists paths, which are derived from
macros?
$ rpm -E %python_sitearch
/usr/lib64/python2.7/site-packages
If you build on a system where %{_libdir} is /usr/lib64, you cannot use
the file paths in your "build root", because you would need to substitute
/usr/lib64 with %{_libdir}. How do you handle packages, where paths include
a version number that changes during upgrades?
Do you need to mark files as %doc manually, too?
> 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.
>
$ rpmdev-newspec foo
foo.spec created; type minimal, rpm version >= 4.11.
In that generated file are not many lines to fill in.
On top of that there are small but helpful HOWTOs nowadays, such as:
https://fedoraproject.org/wiki/How_to_create_an_RPM_package
> Once a packager "out-grows" togo, they'll be making manual modifications to their spec-file as has always been done.
>
Well, based on the examples, I don't see how it simplifies building a tiny
RPM package. Hence my comments. I'd like to understand what Togo tries to
simplify/accomplish.
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
