Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#47 RPM: Use noreplace for config or not?

3.1
closed-wont-fix
nobody
Research (4)
5
2008-04-11
2002-09-02
Anonymous
No

Just downloaded the 3.0 rpm for redhat, and upgraded my
old install. Privoxy couldn't start, saying it was
unable to find actionsfile default.action.action.
Changed actionsfile line in /etc/privoxy/config to
default
from
default.action
fixed the problem. Glancing at the code, it appears
that .action is being appended to the actionsfile
input, but nowhere else.

Discussion

1 2 > >> (Page 1 of 2)
  • Hal Burgiss
    Hal Burgiss
    2002-09-02

    • status: open --> pending
     
  • Hal Burgiss
    Hal Burgiss
    2002-09-02

    Logged In: YES
    user_id=322640

    a) Where did you download from?
    b) What version did you upgrade from?
    c) What version does your 'config' file correspond to?

    You probably had a much older config file in place, as a
    clean install does not do this (just tested with SF rpm).
    This behavior was changed (IIRC), several releases ago, and
    as of the official stable release action files are specified
    just with the stub, e.g. 'default'.

    Maybe we should be overwriting 'config'? As of now config
    and user.action are preserved during upgrades. Comments?

     
  • Hal Burgiss
    Hal Burgiss
    2002-09-02

    • labels: --> 103838
     
  • Logged In: YES
    user_id=78811

    > Comments?

    That's the downside of the noreplace option.

    1.) If we don't use it, users have to port/copy their
    settings from the .rpmsaves manually after each
    Privoxy upgrade.

    2.) If we use it, a change in config syntax breaks
    existing setups. Note that this is maybe not as
    bad as 1.) since if there were customizations
    to the config files, they would have to be ported
    manually anyway.

    If we only use it if a file's syntax has not changed
    since the last version, we'll provide a safe & lazy
    upgrade path for those who follow every release,
    and still strike those who skip some releases
    with either of the above problems.

    Since I don't see any smarter way provided by the
    package system (such as marking config files
    with a syntax revision no), I guess plan 3 is the
    way to go?

    RPM gurus?

     
    • status: pending --> open
     
  • Hal Burgiss
    Hal Burgiss
    2002-09-02

    Logged In: YES
    user_id=322640

    >If we only use it if a file's syntax has not changed
    >since the last version, we'll provide a safe & lazy

    Assuming I understand you .... we can't know what version
    the user is upgrading from. Maybe he is 2.9.10 -> 3.0.0. So
    the 2.9.20 users are good (no changes at all), but at some
    point (unknown to rpm), there becomes a problem.

    I would propose that during beta cycles we use noreplace.
    The user should be prepared for such minor annoyances like
    config files breaking. But this is bad on a stable release,
    so the noreplace option should not be included in a stable
    release -- IMO. I meant to suggest this way back when, but
    it slipped my mind. Of coures, this might annoy those
    testers that follow every release, but again they are
    testing pre-release stuff, and should happily expect an
    occasional bump in the road :)

    The problem with this having noreplace option present
    always, except for stable releases, means human intervention
    to change it.

    My best idea is say we move to like:

    current/redhat/specfile.in
    current/redhat/Makefile

    then the local Makefile can play with the specfile and
    generate different ones depending on the stable flag. But it
    would be good to hear from Rodrigo or Karsten on this, or
    for a better approach.

    This is far from ideal, since as you say there just is no
    way to set a version dependent flag during the actual
    installation/upgrade (AFAIK). Or could we use the obsolete
    directive???

    There is some grief for someone either way.

     
  • Hal Burgiss
    Hal Burgiss
    2002-09-02

    Logged In: YES
    user_id=322640

    PS -- Andreas, how much trouble to have the code test for
    *action and *filter, and only append if the extension is not
    present. So default.action gets untouched, and default gets
    changed to default.action. ??? This might forestall some
    future bug reports.

     
  • Logged In: NO

    I upgraded from 2.9.14, and I didn't even notice you hadn't
    replaced my config file; I assumed that it had been
    overwritten. I thought there was a disconnect between the
    code/doc and the config file proviced.

    Related to this, why is .action appended to the actionsfile
    section, but the appropriate suffix is appended to the
    others? Wouldn't it make more sense to have all sections
    behave the same way?

     
  • Hal Burgiss
    Hal Burgiss
    2002-09-03

    Logged In: YES
    user_id=322640

    >Wouldn't it make more sense to have all sections
    >behave the same way?

    It would be more consistent. This has come up before, so I
    suspect it might be addressed in the next stable series
    (3.2). I don't think we will be making config file changes
    until then (due to upgrade type problems like this).

    Thanks for your interest.

    Leaving this open, hoping for the RPM masters to chime in :)

     
    • milestone: 188501 -->
    • labels: 103838 -->
    • summary: .action being appended to actionsfile --> RPM: Use noreplace for config or not?
    • status: open --> open-wont-fix
     
1 2 > >> (Page 1 of 2)