Re: (proposal) new flag for pkg_delete

From: David Taylor (davidt_at_yadt.co.uk)
Date: 09/03/03

  • Next message: The Anarcat: "config files in packages (Re: (proposal) new flag for pkg_delete)" 
    Date: Wed, 3 Sep 2003 19:29:25 +0100
To: freebsd-arch@freebsd.org

    On Wed, 03 Sep 2003, Will Andrews wrote:

    > On Wed, Sep 03, 2003 at 03:39:48PM +0100, David Taylor wrote:
    > > It fails to mention that if -f is specified it will also delete any files
    > > where the MD5 checksum is incorrect. I have now been repeatedly bitten by
    > > portupgrade wiping my configuration information because it specifies -f
    > > (as it must, in order to remove packages which are still 'in use' by other
    > > packages).
    >
    > Wrong way to fix the problem. Make the ports install sample
    > config files and only add those to the plist, not the actual ones.
    >

    As I stated in my previous reply, I am aware this is a real problem (which
    I would also like to fix, in a more 'proper' way than the pkg_delete
    patch), so I have another suggestion.

    However, I beleive this suggestion has been made repeatedly before, but
    noone has ever come to an agreement, mainly because noone has ever done
    much to make it happen.

    The suggestion is, to use a mergemaster style tool to handle port/pkg
    config files. Whilst we're at it, the base system mergmaster could
    (optionally?) use the new system to.

    The main features I could see as desirable would be:

            Package/port installed config files will not overwrite any files.

            Deinstalling packages/ports will not by default remove config data.

            Merging of changes from distributed config files against
            local versions.

    I have an idea which appears to satisfy all of those goals, but
    unfortunately uses RCS. It may turn out it would be easier to use CVS.
    I would prefer to use a non RCS/CVS tool, because they are fairly
    'difficult' tools, and making users use them as part of the ports system
    is not perhaps a great idea. Hopefully the needs of the config system
    would not tickle any bugs in RCS/CVS and can use other tools around the
    rcs/cvs commands, to prevent users shooting themselves in the foot.

    Enough babbling, the idea essentially is:

    (Bad ASCII Art diagram 1: Example rcs 'tree' for a config file)
    dist_1 -> dist_2 -> dist_3 -> dist_4
     1.1 1.2 1.3 1.4
     \ \ \
      \ \ \
       | | |
      user_1a user_2a user_3a
       1.1.1.1 1.2.1.1 1.3.1.1
       | |
       | |
      user_1b user_2b
       1.1.1.2 1.2.1.2

    Ports (using some tool [pkgcfg_install ?]) install new config files on to
    the head branch (dist_* in the diagram). Another user tool (pkgcfg_merge)
    merges any differences, and checks in the user accepted version on to the
    corresponding branch:

    For dist_1 it would display the new file, and store the editted version
    (if different) on the 1.1.1 branch.

    For dist_2 it would display a 3 way diff style view of the changes between
    dist_1 -> dist_2, merged into user_1b (the tip of the 1.1.1 branch).

    The revision (or branch) number of the latest user revision would need to
    be stored somewhere (probably in /var/db/pkg).

    Thus, ports could add new config files to the rcs file without affecting
    users, who could simply run 'pkgcfg_merge' to view diffs of what has
    changed. Upon deinstallation, nothing need happen -- although the config
    file could be backed up in to the rcs file, then removed. On
    re-installation, a port could detect the existing config file, and check
    that out.

    The rcs file could be optionally removed on deinstallation, and a tool
    would be able to allow their removal fairly easy.

    If I could find a better way than RCS/CVS to do this, I would probably
    starting hacking at it tomorrow some time.

    Unless someone can see an obvious flaw in my grand scheme? :) 

    -- 
David Taylor
davidt@yadt.co.uk
"The future just ain't what it used to be"
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: The Anarcat: "config files in packages (Re: (proposal) new flag for pkg_delete)"

    Relevant Pages

    • xdm config files overwritten after upgrading Xfree86-clients from ports
      ... I upgraded Xfree86-clients from ports using portupgrade today and noticed that ... After some searching i found that the config files in /usr/X11R6/lib/X11/xdm had ... Should i manually inspect my config files after each portupgrade? ... Or is this just a bug in XFree86-clients (and possibly some other ports)? ...
      (freebsd-questions)
    • Re: (proposal) new flag for pkg_delete
      ... >> packages). ... Make the ports install sample ... I agree that ports should be fixed to install config files in the correct ...
      (freebsd-arch)
    • Re: SMB vs NFS
      ... > the parent poster who was speculating. ... > be sharing are personal config files with nothing sensitive in them. ... Given that you were planning to use SMB ports, ... Time flies like an arrow, ...
      (comp.os.linux.networking)
    • Problems creating a new release
      ... with almost no sourcecode change. ... world and some of my favorite ports into this directory. ... modified a shellscript I often use for installation, ... create the config files based on the user's hardware ...
      (freebsd-questions)