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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging