Re: RFS: figtoipe - Debian

This is a discussion on Re: RFS: figtoipe - Debian ; OoO En cette fin de matinée radieuse du samedi 17 mai 2008, vers 11:17, Alexander Bürger disait: >> When using Conflicts and having files in common with the other package, >> you need Replaces as well. Otherwise, during upgrade, the ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Re: RFS: figtoipe

  1. Re: RFS: figtoipe

    OoO En cette fin de matinée radieuse du samedi 17 mai 2008, vers 11:17,
    Alexander Bürger disait:

    >> When using Conflicts and having files in common with the other package,
    >> you need Replaces as well. Otherwise, during upgrade, the user may see
    >> error messages about your package trying to erase files owned by the
    >> other (not yet removed) package.


    > So what do you think about section 7.5 in the policy manual? As I said,
    > to me it is confusing. It does not explicitly say that Replaces: must
    > come together with Conflicts:, it sounds more like there are different
    > meanings if it is alone (replace only some files) or with Conflicts:
    > (replace whole package).


    Hi Alexander!

    [This message is about using Replaces without Conflicts]

    I am not sure either. As you noted, the policy does not say to not use
    it alone, but this just seems odd to me. Let's hope that someone else
    will enlighten us on this matter.

    The valid way to replace a file without conflicting with a package is to
    use diversion. This is not a solution in your case because you would
    have to ask maintainer of ipe to use diversion too and since figtoipe is
    no longer shipped with ipe, he won't be able to.
    --
    /*
    * For moronic filesystems that do not allow holes in file.
    * We may have to extend the file.
    */
    2.4.0-test2 /usr/src/linux/fs/buffer.c

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFILqW/KFvXofIqeU4RAtPmAJ9Uw7YrSOjMmQGyVcWuVcMIUUIuYQCcCi qI
    anpXOntS7aUGTl9meW76gZ0=
    =bVhp
    -----END PGP SIGNATURE-----

  2. Re: RFS: figtoipe / difficulties with Replaces:

    Hi,

    0================================================= =====================0
    Info for debian-devel: we try to figure out how to package figtoipe.
    Before version 6.0pre30-1, a version of figtoipe was included in the ipe
    package. Since then, figtoipe is a separate upstream package and also
    gone from the ipe .deb. A new version of figtoipe, which is improved and
    has fewer bugs than the one coming with older ipe versions, exists and
    shall be packaged for debian in a way that it can be installed together
    with any ipe version.
    0============================================== ========================0

    > > So what do you think about section 7.5 in the policy manual? As I said,
    > > to me it is confusing. It does not explicitly say that Replaces: must
    > > come together with Conflicts:, it sounds more like there are different
    > > meanings if it is alone (replace only some files) or with Conflicts:
    > > (replace whole package).

    >
    > I am not sure either. As you noted, the policy does not say to not use
    > it alone, but this just seems odd to me. Let's hope that someone else
    > will enlighten us on this matter.


    I made a little experiment. I created two packages "twoprog" version
    0.1-1, containing progone and progtwo, and "oneprog" version 0.1-1 which
    contains only an "improved version" of oneprog. In oneprog's
    debian/control, I put

    Replaces: twoprog (<= 0.1-1)

    I first installed twoprog 0.1-1, then oneprog 0.1-1, and the
    installation of oneprog gives a message

    Replacing files in old package twoprog.

    which is fine. After installing oneprog, the progone script is no longer
    listed with dpkg -L, as expected from the policy description. So far so
    good.

    But when I then remove oneprog, twoprog does not get back its own
    version of progone, the file is still gone. I think this is bad, because
    the twoprog package lost some of its content by installing and removing
    a different package, oneprog (dpkg version 1.14.18).

    Also when I install version 0.2-1 of twoprog (which does no longer come
    with its own progone), there is no error. But an error occurs when I
    then try to downgrade towprog back to version 0.1-1 because the package
    would overwrite progone from the oneprog package.

    In summary: it's a mess because dpkg does not remember which files were
    replaced and what the original versions had been. On the other hand, I
    do not see easily how the logic should be.

    So, what should we do?

    Best wishes,

    Alexander



    --
    To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: RFS: figtoipe


    Hello,

    Vincent Bernat wrote:
    > The valid way to replace a file without conflicting with a package is to
    > use diversion. This is not a solution in your case because you would
    > have to ask maintainer of ipe to use diversion too and since figtoipe is
    > no longer shipped with ipe, he won't be able to.


    diversions don't require that all packages providing the file divert
    the file. This is alternatives you're thinking about. Installing a
    diversion for the file is probably the right way to go.

    Cheers,

    Vincent

    --
    Vincent Fourmond, Debian Developer
    http://vince-debian.blogspot.com/

    find(1):

    A `%' at the end of the format argument causes undefined behaviour
    since there is no following character. In some locales, it may
    hide your door keys, while in others it may remove the final page
    from the novel you are reading.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: RFS: figtoipe

    OoO Vers la fin de l'après-midi du samedi 17 mai 2008, vers 16:02,
    Vincent Fourmond disait:

    > Vincent Bernat wrote:
    >> The valid way to replace a file without conflicting with a package is to
    >> use diversion. This is not a solution in your case because you would
    >> have to ask maintainer of ipe to use diversion too and since figtoipe is
    >> no longer shipped with ipe, he won't be able to.


    > diversions don't require that all packages providing the file divert
    > the file. This is alternatives you're thinking about. Installing a
    > diversion for the file is probably the right way to go.


    Oh, you are right. So yes, diversion seems the best pick.
    --
    panic ("No CPUs found. System halted.\n");
    2.4.3 linux/arch/parisc/kernel/setup.c

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFILuqCKFvXofIqeU4RAiiGAJ92+Nf+EdzKVQ+Q5RLaYS fDVmhh5ACfSZJ+
    gCauJs9txZ/LO28E0joKR2s=
    =WvwI
    -----END PGP SIGNATURE-----

  5. Re: RFS: figtoipe

    On Sat, 17 May 08 11:30, Vincent Bernat wrote:
    > OoO En cette fin de matinée radieuse du samedi 17 mai 2008, vers 11:17,
    > Alexander Bürger disait:
    >
    > >> When using Conflicts and having files in common with the other package,
    > >> you need Replaces as well. Otherwise, during upgrade, the user may see
    > >> error messages about your package trying to erase files owned by the
    > >> other (not yet removed) package.

    >
    > > So what do you think about section 7.5 in the policy manual? As I said,
    > > to me it is confusing. It does not explicitly say that Replaces: must
    > > come together with Conflicts:, it sounds more like there are different
    > > meanings if it is alone (replace only some files) or with Conflicts:
    > > (replace whole package).

    >
    > Hi Alexander!
    >
    > [This message is about using Replaces without Conflicts]
    >
    > I am not sure either. As you noted, the policy does not say to not use
    > it alone, but this just seems odd to me. Let's hope that someone else
    > will enlighten us on this matter.


    Replaces must not come with Conflicts.
    Consider a package foo which contains a lot of architecture independent
    files. One day you decide to split the arch independent files into a new
    package foo-data. foo-data will replace the old foo package, but there
    is no need to conflict with it.

    You just need a conflict, when the package where the common file
    originally comes from must be gone, after you installed your package.

    HTH
    Armin


    --
    To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: RFS: figtoipe

    On 17-May-08, 04:30 (CDT), Vincent Bernat wrote:
    > [This message is about using Replaces without Conflicts]
    >
    > I am not sure either. As you noted, the policy does not say to not use
    > it alone, but this just seems odd to me. Let's hope that someone else
    > will enlighten us on this matter.


    While it doesn't apply to this specific case (in which a diversion
    would seem to be the correct choice), here's how Rplaces and Conflicts
    interact:

    Package B "Replaces" package A: when B is installed, any files that are
    also in A will be taken over by B, and removed from A's list of owned
    files, so that if A is later removed, it won't delete the files that B
    replaced. Non-conflicting files remain with package A.

    Package B "Conflicts" with package A: dpkg will prevent you from
    installing them at the same time.

    Package B "Replaces" *and* "Conflicts" with package A: when B is
    installed, any files that are also in A will be taken over by B, as in
    the "Replaces" only case. In *addition*, any remaining files in A will
    be *removed*, and package A will be considered removed from the system.

    Regards,
    Steve
    --
    Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world. -- seen on the net


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: RFS: figtoipe / difficulties with Replaces:

    On Sat, May 17, 2008 at 03:48:03PM +0200, Alexander Bürger was heard to say:
    > 0================================================= =====================0
    > Info for debian-devel: we try to figure out how to package figtoipe.
    > Before version 6.0pre30-1, a version of figtoipe was included in the ipe
    > package. Since then, figtoipe is a separate upstream package and also
    > gone from the ipe .deb. A new version of figtoipe, which is improved and
    > has fewer bugs than the one coming with older ipe versions, exists and
    > shall be packaged for debian in a way that it can be installed together
    > with any ipe version.
    > 0============================================== ========================0


    I don't understand the question enough, I guess. What's wrong with
    the usual solution? i.e.,

    figtoipe Replaces ipe (< 6.0pre30-1)
    figtoipe Conflicts ipe (< 6.0pre30-1)

    Using Replaces on its own seems bizarre to me. OTOH, some packages do
    this; e.g., xfce4 Replaces xfce4-dev without conflicting with it. [0]

    Daniel

    [0] you can get the full list with

    aptitude search '?for x: ?replaces(?for y:?not(?x:conflicts(?=y)))'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: RFS: figtoipe

    OoO Lors de la soirée naissante du samedi 17 mai 2008, vers 17:57, Armin
    Berres disait:

    > Replaces must not come with Conflicts.
    > Consider a package foo which contains a lot of architecture independent
    > files. One day you decide to split the arch independent files into a new
    > package foo-data. foo-data will replace the old foo package, but there
    > is no need to conflict with it.


    Even against older versions? You have one package foo-0.5.2-1, you split
    it in foo-0.5.2-2 and foo-data-0.5.2-2. Should not foo-data-0.5.2-2
    conflicts with foo (<= 0.5.2-1)? This is not a very realistic example
    because in this case, I suppose that foo will depend on foo-data (=
    ${binary:Version}).

    Thanks for any insight.
    --
    printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
    2.2.16 /usr/src/linux/drivers/char/msp3400.c

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFILyasKFvXofIqeU4RAlldAJ9K6dHoTRvo21yb6x4GYf fiKM3g6ACeKhXR
    4Aal3WxW0s91590QeNqNbA0=
    =k4jT
    -----END PGP SIGNATURE-----

  9. Re: RFS: figtoipe

    On Sat, 17 May 08 20:40, Vincent Bernat wrote:
    > OoO Lors de la soirée naissante du samedi 17 mai 2008, vers 17:57, Armin
    > Berres disait:
    >
    > > Replaces must not come with Conflicts.
    > > Consider a package foo which contains a lot of architecture independent
    > > files. One day you decide to split the arch independent files into a new
    > > package foo-data. foo-data will replace the old foo package, but there
    > > is no need to conflict with it.

    >
    > Even against older versions? You have one package foo-0.5.2-1, you split
    > it in foo-0.5.2-2 and foo-data-0.5.2-2. Should not foo-data-0.5.2-2
    > conflicts with foo (<= 0.5.2-1)? This is not a very realistic example
    > because in this case, I suppose that foo will depend on foo-data (=
    > ${binary:Version}).


    There is one quite important paragraph in the policy:
    'A Conflicts entry should almost never have an "earlier than" version
    clause. This would prevent dpkg from upgrading or installing the package
    which declared such a conflict until the upgrade or removal of the
    conflicted-with package had been completed.'
    So you normally only add a conflict, if the package you want to conflict
    with should completely vanish. If you just have a simple package split
    you definitely don't want one package to vanish.

    In the above case there is no problem with foo-data-0.5.2-2 not
    conflicting with foo (<= 0.5.2-1). Consider the case when foo-0.5.2-1 is
    installed. What happens now if you install foo-data-0.5.2-2? The
    ownership of the data files will change, nothing else. foo-0.5.2-1 is
    still completely functional.
    After the package has been split foo should have a dependency on
    something like foo-data (>= ${source:Version}) (not ${binary:Version},
    foo-data is arch all) and you won't have a problem if you just install
    foo-0.5.2-2. It will pull in foo-data-0.5.2-2.

    Maybe the problem you see is the following: When one has
    foo-0.5.2-1 and foo-data-0.5.2-2 installed and removes foo-data-0.5.2-2,
    foo-0.5.2-1 is broken. That's true, but I'd say you get what you
    request, simply don't do such things.

    Greetings,
    Armin


    --
    To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: RFS: figtoipe / difficulties with Replaces:

    On 17-May-08, 11:51 (CDT), Daniel Burrows wrote:
    > Using Replaces on its own seems bizarre to me. OTOH, some packages do
    > this; e.g., xfce4 Replaces xfce4-dev without conflicting with it. [0]


    It's not bizarre. That's how you move files from one package to another.

    It would be nifty if you could explicitly list the files being Replaced,
    to avoid accidents, but I suspect there are more important things to be
    done.

    Steve
    --
    Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world. -- seen on the net


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread