RFC: gnome-vfs -> bonobo symbol migration and indirect Depends/Build-Depends

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: gnome-vfs -> bonobo symbol migration and indirect Depends/Build-Depends

Loïc Minier
        Hi,

 Symbol have moved from gnome-vfs towards bonobo.  The appropriate
 conflict has been added to ensure that you can't end up without the
 symbols if you need them.

 But this conflict causes a lot of complexity to compute the necessary
 build-deps.  Of course, it will "just work" if the only versions
 available to the buildd satisfy the build-deps, and their deps and
 conflicts, but this is really problematic for:
 - experimental
 - backports
 - and perhaps if we don't notice that the default version is
   incompatible, but archive rebuilds before releases shoudl guard
   against this
 (But in the end, we will end up with more restrictive build-deps than
 what the sources truly permit.)

 I would like to complete the transition on the side of build-deps and
 deps as well, that is bump up build-deps and/or deps appropriately so
 that any version which satisfies the build-deps of a package is not
 discovered later on to conflict with another build-dep or a dep of a
 build-dep.

 An example of the problem is gedit, which build-depends on gnome-vfs2
 >= 2.16, and libgnomeui >= 2.16.  libgnomeui depends on libbonoboui >=
 2.13, which depends on libbonobo >= 2.13.  But gnome-vfs2 2.16
 conflicts with libbonobo < 2.15.

 I currently see two ways to transition to a simpler situation, but
 other ways would be valuable of course:
 1) transition each inter-dependency: bump up the rdeps on
 libgnomevfs2-dev and libbonobo2-dev to transitionned version; for
 example libbonoboui2-dev $someversion would depend on libbonobo2-dev >=
 2.16, and libgnomeui-dev would depend on libbonoboui2-dev >=
 $someversion
 2) add dependencies or build-dependencies on lower level libs in high
 level libs: gedit would build-depend on libbonobo2-dev >= 2.16

 I don't like the second solution as it "leaks" low level libs deps to
 higher level stuff, and I don't like the former solution because it
 will bump a lot of inter-dependencies which are in the middle of the
 stack and will cause a lot of work.

   Bye,
--
Loïc Minier <[hidden email]>
 "Forget your stupid theme park! I'm gonna make my own! With hookers!
  And blackjack! In fact, forget the theme park!"          -- Bender


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: gnome-vfs -> bonobo symbol migration and indirect Depends/Build-Depends

Josselin Mouette
Le vendredi 22 décembre 2006 à 15:53 +0100, Loïc Minier a écrit :
>  An example of the problem is gedit, which build-depends on gnome-vfs2
>  >= 2.16, and libgnomeui >= 2.16.  libgnomeui depends on libbonoboui >=
>  2.13, which depends on libbonobo >= 2.13.  But gnome-vfs2 2.16
>  conflicts with libbonobo < 2.15.

Which means APT will automatically install libbonobo 2.16 in this case.

Could you explain how this will exactly cause trouble?

>  I currently see two ways to transition to a simpler situation, but
>  other ways would be valuable of course:
>  1) transition each inter-dependency: bump up the rdeps on
>  libgnomevfs2-dev and libbonobo2-dev to transitionned version; for
>  example libbonoboui2-dev $someversion would depend on libbonobo2-dev >=
>  2.16, and libgnomeui-dev would depend on libbonoboui2-dev >=
>  $someversion
>  2) add dependencies or build-dependencies on lower level libs in high
>  level libs: gedit would build-depend on libbonobo2-dev >= 2.16
>
>  I don't like the second solution as it "leaks" low level libs deps to
>  higher level stuff, and I don't like the former solution because it
>  will bump a lot of inter-dependencies which are in the middle of the
>  stack and will cause a lot of work.
Solution 1 means introducing a complete madness in libraries, and soon
we won't know which dependency means what. Solution 2 is cleaner, but I
think we should avoid that if possible. If this is for setting up an
autobuilder for experimental packages or backports, this problem should
be dealt with by a clever enough autobuilding script. For example, for
building gnome-2.16 related packages, it could install all
build-depencies at the 2.16 version.

--
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

signature.asc (196 bytes) Download Attachment