On Apr 28, 2016, at 4:43 AM, Elan Ruusamäe wrote:
> On 27.04.2016 21:09, Jeff Johnson wrote:
>> What I am suggesting is using --justdb --noscripts --notriggers on the v2
>> package before attempting an upgrade.
>
> you're solving the problem in wrong order. suggesting to use --justdb
> --notri
On Apr 28, 2016, at 4:41 AM, Elan Ruusamäe wrote:
>
> but rpm i use to manage configuration and expect %noreplace to mean "do not
> replace the file". that one technical detail makes it behave differently on
> high level does not change my expectation. i'd rather consider it flaw in
> impleme
On 27.04.2016 21:09, Jeff Johnson wrote:
What I am suggesting is using --justdb --noscripts --notriggers on the v2
package before attempting an upgrade.
you're solving the problem in wrong order. suggesting to use --justdb
--notriggers --notriggers means i already know that specific package
On 27.04.2016 20:08, Jeff Johnson wrote:
I doubt you would be surprised if you extracted a tar archive that "destroyed"
secret_key.php,
particularly if you had forgotten to add options that might have prevented
overwriting. Similarly,
if you added tar options wrongly and then found that, say, a
On 27.04.2016 20:08, Jeff Johnson wrote:
In the v1 package, secret_key.php is_NOT_ in a package.
Which means:
1) there is no way to tell if the file is modified, owned, timestamped,
should be present, etc.
i will make it very short of my expectation on rpm behaviour:
as there's no way
On Apr 27, 2016, at 1:08 PM, Jeff Johnson wrote:
>
> So why are you claiming RPM "destroyed" your secret_key.php file when you are
> misusing
> %config(noreplace)
> with expectations of behavior that have never been implemented, and cannot be
> implemented
> because there is no reference
On Apr 27, 2016, at 10:12 AM, Elan Ruusamäe wrote:
> On 27.04.2016 16:55, Jeff Johnson wrote:
>> On Apr 27, 2016, at 3:13 AM, Elan Ruusamäe wrote:
>>
>>> and it did it again!
>>>
>> You are smart enough to identify a better solution for your problems than
>> blaming RPM
>> for destroying your
On 27.04.2016 16:55, Jeff Johnson wrote:
On Apr 27, 2016, at 3:13 AM, Elan Ruusamäe wrote:
and it did it again!
You are smart enough to identify a better solution for your problems than
blaming RPM
for destroying your files ... again ... and again.
meh?
i described scenario that is comple
On Apr 27, 2016, at 3:13 AM, Elan Ruusamäe wrote:
> and it did it again!
>
You are smart enough to identify a better solution for your problems than
blaming RPM
for destroying your files ... again ... and again.
73 de Jeff
___
pld-devel-en mailing
and it did it again!
scenario:
package version1 installed,
i have file secret_key.php in filesystem, which is not (yet) packaged.
i create package version2, which has:
%attr(640,root,http) %config(noreplace) %verify(not md5 mtime size)
%{_webappdir}/secret_key.php
secret_key.php is 0 byte fil
10 matches
Mail list logo
