Please provide xlibs compatibility package

Backports packages must come from Edgy.

This has been discussed to death in other bugs. xlibs is a dead package. Packages that still depends on it must be fixed.

Regardless of package dependencies, it's useful to have a way to install this set of libraries in one shot.

Matt this package has been dropped also from upstream (debian). It would only introduce another delta that we don't really want to carry around.

Fabio

On Tue, Oct 03, 2006 at 03:50:06PM -0000, Fabio Massimo Di Nitto wrote:
> Matt this package has been dropped also from upstream (debian). It would
> only introduce another delta that we don't really want to carry around.

It makes sense to retain this package in Debian as well; do you know why it
was removed? If it was only to break packages in order to force them to
transition away from xlibs, then it can probably be restored now.

--
 - mdz

xorg (1:7.0.6) experimental; urgency=low

  * At the urgent request of the release and ftp teams, xlibs must die. Have
    the xserver-xorg package recommend xkb-data instead. xkb-data should
    already be pulled in by several pieces including the xorg metapackage,
    xutils, and xbase-clients

but the main reason is that since xlibs-static-dev and xlibs-dev are not there anylonger, there is very little point to carry around a xlibs.
Each package will need to B-D on the proper -dev and dh_shlibs will build the correct Depends: line for them.

while we can agree that installing all the xlibs is not that expensive (size wise) other people would complain that for a 4KB x apps that only requires libx11-6, they don't want to install 20MB of extra stuff because of maintainer lazyness.

so it has been agreed to do it right and in full and kill the package.

Also to note that we don't have xlibs in dapper. Reintroducing it would be just pointless when all the other packages are transitioning.

Fabio

On Tue, Oct 03, 2006 at 04:40:35PM -0000, Fabio Massimo Di Nitto wrote:
> xorg (1:7.0.6) experimental; urgency=low
>
> * At the urgent request of the release and ftp teams, xlibs must die. Have
> the xserver-xorg package recommend xkb-data instead. xkb-data should
> already be pulled in by several pieces including the xorg metapackage,
> xutils, and xbase-clients
>
> but the main reason is that since xlibs-static-dev and xlibs-dev are not there anylonger, there is very little point to carry around a xlibs.
> Each package will need to B-D on the proper -dev and dh_shlibs will build the correct Depends: line for them.
>
> while we can agree that installing all the xlibs is not that expensive
> (size wise) other people would complain that for a 4KB x apps that only
> requires libx11-6, they don't want to install 20MB of extra stuff
> because of maintainer lazyness.
>
> so it has been agreed to do it right and in full and kill the package.
>
> Also to note that we don't have xlibs in dapper. Reintroducing it would
> be just pointless when all the other packages are transitioning.

Please understand, I am not suggesting that packages depend or build-depend
on xlibs, only that it exist as a convenience for users to install who want
to have the standard set of libraries. I still do not understand why it was
removed in the first place as it was not necessary for the dependency
transition.

--
 - mdz

* Matt Zimmerman

| Please understand, I am not suggesting that packages depend or build-depend
| on xlibs, only that it exist as a convenience for users to install who want
| to have the standard set of libraries.

Isn't this what we have dependencies for? I can't think of why a user
would care about what libraries he's got installed.

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
                                                                      `. `'
                                                                        `-

Umm, well the one instance I can think of is when Opera's original 9.00 debs depended on xlibs instead of the new library names, people could not install the debs and started inventing crackpot ways of extracting the binaries into their filesystem tree.

John Dong skrev:
> Umm, well the one instance I can think of is when Opera's original 9.00
> debs depended on xlibs instead of the new library names, people could
> not install the debs and started inventing crackpot ways of extracting
> the binaries into their filesystem tree.

Those packages had other problems as well, so not having them
installable was in reality a good thing and it meant we ended up getting
in touch and working together in a useful relationship.

(Which reminds me I need to email them about the newest version too).

- tfheen

On Thu, Oct 05, 2006 at 01:52:35PM -0000, Tollef Fog Heen wrote:
> * Matt Zimmerman
>
> | Please understand, I am not suggesting that packages depend or build-depend
> | on xlibs, only that it exist as a convenience for users to install who want
> | to have the standard set of libraries.
>
> Isn't this what we have dependencies for? I can't think of why a user
> would care about what libraries he's got installed.

It's useful when installing software from sources other than Ubuntu. For
example, the IBM JDK is popular, and its dependencies are not trivial
anymore now that the libraries are split.

--
 - mdz

I suppose tfheen will tell you that the IBM JDK package is crap and users should not install it until he works out a relationship with IBM to provide perpetually outdated IBM JDK packages...

On Thu, Oct 05, 2006 at 05:54:03PM -0000, John Dong wrote:
> I suppose tfheen will tell you that the IBM JDK package is crap and
> users should not install it until he works out a relationship with IBM
> to provide perpetually outdated IBM JDK packages...

Let's keep this discussion at a constructive level.

You've missed the point; users sometimes need to install software which is
not shipped in packaged format, and for odd reasons they often expect the
traditional set of X libraries to be available.

--
 - mdz

Matt, can we not just recommend that users install xorg-dev instead? That already exists and is supported by Debian too.

(Ah, well, that's for xlibs-dev, not xlibs, although it would do the job in a somewhat heavy-handed way ...)

Is a compatibility package still desired? I don't think so, but an update of where we stand now is needed.

On Fri, Nov 30, 2007 at 06:41:28AM -0000, Timo Aaltonen wrote:
> Is a compatibility package still desired? I don't think so, but an
> update of where we stand now is needed.

Any problems we created by not providing one are already with us, so I think
it's too late to try to address them in this way.

--
 - mdz

Right, closing the bug. This has been mostly fixed anyway by vendors who have updated their packaging (opera being an example).