Proposal mass bug filling on packages depending on xlibs(?)

[Ondrej Sury]

On Sun, 2005-07-31 at 15:55 -0500, Ming Hua wrote:
> On Sun, Jul 31, 2005 at 10:18:59PM +0200, Ondrej Sury wrote:
> > On Sun, 2005-07-31 at 14:52 -0500, Ming Hua wrote:
> > > On Sun, Jul 31, 2005 at 01:52:56PM +0200, Ondrej Sury wrote:
> > > > 
> > > > I know that xorg transition is still ongoing, but it seems that
> > > > depending on "| xlibs (>> 4.1.0)" will be wrong for Breezy anyway.
> > > > And it's better to speak now than too late, isn't it? :-)
> > > 
> > > I am not an expert on this, but IIUC this dependency is generated by
> > > dh_shlibdeps automatically, which in turn comes from the shlibs of X lib
> > > packages.  So there should be no mass bug filing anyway, all the changes
> > > should be done in X.org packages.  Am I right?
> > 
> > Yes and no. :-)  Dependencies are generated by dh_shlibdeps, but you
> > need to recompile all packages against new libx* with changed shlibs, if
> > you want to get rid of dependency on xlibs.
> 
> I see, thanks for the explanation.
> 
> But since Daniel has already decided to reintroduce the libx*
> dependencies to xlibs, things should work out, shouldn't it?  I am not
> following breezy, but looking at the xorg 6.8.2 packages in Debian sid,
> it seems most old xlibs don't change SONAMEs.  So I suppose it's fine
> for them to still put "| xlibs (>> 4.1.0)" in their shlibs.  Of course,
> the new libx* packages and SONAME-changed packages (libxaw8, anything
> else?) should drop them.
> 
> So would you please elaborate what you mean by "but it seems that
> depending on '| xlibs (>> 4.1.0)' will be wrong for Breezy anyway"?

Well, it seems useless to depend on transitional package, isn't it?
My opinion is that Daniel should change shlibs to not include xlibs, so
newly compiled package won't depend on xlibs (transitional package).
I think that there is still plenty of time for Breezy, but dropping
xlibs can be done for Breezy+1 as well.  (That's not up to me to
decide :-).

-- 
Ondrej Sury <ondrej at sury.org>