On 01/30/2014 11:06 AM, Gene wrote:
On Thursday, January 30, 2014 2:04 AM, Panu Matilainen
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 I stand corrected. This makes me happy; I did not like having to change that portion of the original script.
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.
What you fail to realize is that what you claim is the way an RPM is "supposed" to be built has already alienated a large majority of developers from creating RPMs in the first place.
If you can successfully build a package that is able to correctly deploy and configure files and services on a system, then you've built it the way it was "supposed" to be built.
Sorry but no. Given enough time and perseverance, one can probably cut
wood with the blunt end of an axe but its going to be one painful
process compared to using the tool the way its intended to. The same
applies to any piece of software as well.
I've seen more than my share of strange abuses of rpm that all end up
generating an rpm that can be installed on systems but totally miss the
point of and only make simple things incredibly bizarre and
unnecessarily hard due to lack of understanding of a few key concepts.
Let's be honest here; you can lecture and berate people all you want regarding proper policy and procedure, but in the end, people are going to go with the easiest method that meets their requirements.
The easiest way in the end is to learn to properly use the tool. Really.
Otherwise you'll spend a whole lot of time working around problems that
are not really there.
This is not about lecturing or berating, much less about policy or
procedure (following distro packaging policies is an entirely different
topic). This isn't really about togo either - if it works for you then
it works for you. I'm just seeing many tell-tale signs of
misunderstanding how rpm(build) works, which means you're working around
essentially non-existent problems. Mind you, there certainly are several
aspects of rpm packaging that could be simplified and sanitized, such as
the default directory layout.
For the vast majority of people with simple, interpreted scripts to package up, that's gonna be Togo, or something like it.
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.
Well, I'll be.... ya learn somethin new every day!
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.
I said "root directory" - not "root user".
Yes, but you need to be root to change file ownership on the filesystem.
That's why ownership needs to be handled in the %files section, not
filesystem.
- Panu -
-Gene
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
