On Sep 4, 2011, at 3:33 PM, Belal Salem wrote:
> Thanks! According to all of that, I found the best solution just for now, is to rename rpm -> rpm.exec
> and make a 'rpm' script that executes rpm.exec --noparentdirs $* all the time unless I don't want it, I can use rpm.exec itself.
Poifect! Note that I _ALWAYS_ wrap rpm/rpmbuild in ~/bin/*rpm.
You might check the persistence enabled by
rpm --showrc | more
All that the build options is doing is setting/exposing 2 macros.
If the macros default value is "opt-out" rather than "opt-in",
that too would explain what you are seeing (and the AutoFu is
functional as intended: devzero2000 usually does careful AutoFu
but building-with-macro-disablers-for-parentdirs isn't
the same thing as configuring-the-macro-disablers-for-parentdirs-to-off.
That permits me to have multiple versions of RPM installed,
all configured differently, and to be able to do build-install
cycles without having to reconfigure the box itself.
> On Sun, 04 Sep 2011 21:20:33 +0200, devzero2000 <email@example.com> wrote:
>> On Sun, Sep 4, 2011 at 4:47 PM, Jeff Johnson <firstname.lastname@example.org> wrote:
>>> On Jun 4, 2010, at 2:55 AM, Belal Salem wrote:
>>> > Hi there!
>>> > I issued the same issue before, when installing some packages, the RPM
>>> package manager doesn't create the required folders and ask for the folders
>>> as unresolved dependencies, although those folders are part of the package
>>> being installed.
>>> Its "part of the package" which is confusing.
>>> There are two meanings for "part of the package":
>>> 1) directory components as part of file paths
>>> 2) directory explicitly listed in "rpm -qpl *.rpm"
>>> If its not explicitly in the file manifest, its not "part of the package"
>>> and you *will* see what you are reporting.
>>> > Recompiling RPM with the options: --disable-dirname-and-symlink-deps
>>> didn't solve the problem, anyway through that?!
>>> I'm not the person to "fix" --disable-dirname-and-symlink-deps.
>>> My fix will be to rip out the "Have it your own way!" functionality that
>>> isn't "working"
>>> and remove the
>>> in order to simplify RPM's build and clarify "supported" functionality. I
>>> no future in carrying around functionality that doesn't work as it should
>>> and is "vendor supported" by others here @rpm5.org.
>>> I will rip out the option if it isn't fixed by someone else @rpm5.org
>>> this month.
>>> No, it is right that i rip out the option tomorrow. I have introduced it,
>> it is equivalent to "vendor supported" - i am pretty sure - but probably
>> don't work as it should. But if so there should be a spec with
>> directory-symlink broken deps that does not work even in Mandriva for
>> example. I would love to see this spec, possibly for tomorrow. Perhaps ark
>> linux and mandriva could be find useful. Thanks. Best Regards
>> FWIW, this is description of this disabler
>> <goog_702910032>The idea was to simplify bootstrapping distributions that do
>> not use rpm5 as a package manager or that are broken from a QA POW
>> such as RHEL5:
>> in short for simplify rpm5 adoption in first place. I am sure someone @
>> rpm5.org had used patch - not upstream - similar for RHEL5. My memory is not
>> so bad, i have seen this in a mail some year ago. The old dog can have good
>> memory, yes.
>> The idea was
>>> 73 de Jeff
>>> RPM Package Manager http://rpm5.org
>>> User Communication List email@example.com
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> RPM Package Manager http://rpm5.org
> User Communication List firstname.lastname@example.org
Received on Sun Sep 4 22:10:32 2011