[gentoo-dev] Final qt/QTDIR scheme

[gentoo-dev] Final qt/QTDIR scheme

[Dan Armak]

Hi all,

As you may or may not know, during the last three or four days we've had a 
new (-r1) qt ebuild that installed into /usr and consequently did no use 
QTDIR.

However, when (soon) qt-3 comes out, we will have to provide for their 
coexistence. Due to their headers having the same names, they cannot live in 
the same dir.

There were three intermediary schemes to take care of this. If you know about 
them, forget them, they failed.

The current and (I very much hope) final scheme is this:
qtX installs in /usr/lib/${P}. This is qt-x11-${PV} normally. However there 
are also qt-x11-free and qt-embedded libraries which we may have in the 
future, so we don't use /usr/lib/qt-${PV} anymore. A symlink is created in 
/usr/lib/qt-x11-$MAJOR_VERSION. That is, for now, 2 or 3.

There is a problem: files in /etc/env. extend settings. When we have more 
than one QTDIR setting, they will be concatenated and will become meaningless.

Solution:
There is the file /etc/env.d/30qt, which only sets QTDIR. So, the qt 
installed last is the default.

Then, there are files ??qt-x11-$MAJOR_VERSION. The first one is 50qt-x11-2, 
then 49qt-x11-3 and so on. Each of these adds the 
/usr/lib/qt-x11-$MAJOR_VERSION/{bin,lib,share/man} dirs to the paths. These 
don't use QTDIR and do use the symlink dirs. 
The decreasing numbers make certain that later QT versions are given priority 
(i.e. 3 over 2...) because they are closer to the beginning of the paths.

99% of qt apps are also KDE apps and as such use eclasses. A configure script 
should automatically use the qt in QTDIR, which is by default the latest qt. 
Therefore, once kde3 is out, I will make (tiny) qt{2,3}.eclass files that 
will say QTDIR=/usr/lib/qt-x11-$MAJOR_VERSION. kde.eclass itself will have 
QTDIR set to the latest version available.

This way:
- An app inheriting from kde-*.eclass will use the latest qt available.
- An app that needs the not-latest version (e.g. qt2 not 3), will explicitly 
inherit qt$VER.eclass (after kde-*.eclass).
- An app being compiled outside ebuilds, non-kde qt apps, and everything else 
that doesn't use eclasses will have to trust that QTDIR is properly set, or 
to set it manually to /usr/lib/qt-x11-$MAJOR_VERSION (no biggie).

----

Well, that's it. I'm writing this late at night, so I've probably said 
something stupid. Comments welcome!

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Final qt/QTDIR scheme

[Mikael Hallendal]

tis 2001-10-09 klockan 02.34 skrev Dan Armak:
> Hi all,

Hi!

> The current and (I very much hope) final scheme is this:
> qtX installs in /usr/lib/${P}. This is qt-x11-${PV} normally. However there 
> are also qt-x11-free and qt-embedded libraries which we may have in the 
> future, so we don't use /usr/lib/qt-${PV} anymore. A symlink is created in 
> /usr/lib/qt-x11-$MAJOR_VERSION. That is, for now, 2 or 3.

A few questions:

1) What are the difference between qt-x11 and qt-x11-free.

2) Why is it called qt-x11 and not just 'qt'?
   I guess this is because you can build qt-embedded (Is that for 
   framebuffer)? or perhaps there even is a qt-fb for that. Anyway, my 
   point is, why not calling "regular" (x11) qt just plain and simple 
   'qt' and use an extra ending for the others?

> 99% of qt apps are also KDE apps and as such use eclasses. A configure script 
> should automatically use the qt in QTDIR, which is by default the latest qt. 
> Therefore, once kde3 is out, I will make (tiny) qt{2,3}.eclass files that 
> will say QTDIR=/usr/lib/qt-x11-$MAJOR_VERSION. kde.eclass itself will have 
> QTDIR set to the latest version available.

> - An app being compiled outside ebuilds, non-kde qt apps, and everything else 
> that doesn't use eclasses will have to trust that QTDIR is properly set, or 
> to set it manually to /usr/lib/qt-x11-$MAJOR_VERSION (no biggie).

When/if EClasses gets accepted they won't be restricted to KDE-use
(right?) and should probably be used for all qt-apps (and probably
others), meaning that if it's an qt2 app it inherits qt2.eclass and if
it's an qt3 app it inherits qt3.eclass. 

Regards,
  Mikael Hallendal

> Well, that's it. I'm writing this late at night, so I've probably said 
> something stupid. Comments welcome!

Written even later :)

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Final qt/QTDIR scheme

[Dan Armak]

On Tuesday 09 October 2001 05:19, you wrote:
> 1) What are the difference between qt-x11 and qt-x11-free.
qt-x11 comes under the QPL license. This allows to use it freely in 
developing GPL'd apps, or to purchase a license file, install it and develop 
commercial ones.
qt-x11-free allows only the GPL part. It is essentially the same; this 
license is used e.g. for qt3 betas. I'm not going to add those to portage, I 
was just giving an example.

> 2) Why is it called qt-x11 and not just 'qt'?
>    I guess this is because you can build qt-embedded (Is that for
>    framebuffer)? or perhaps there even is a qt-fb for that. Anyway, my
>    point is, why not calling "regular" (x11) qt just plain and simple
>    'qt' and use an extra ending for the others?
Because qt-x11 is the full, proper name. The source archive/dir, for example, 
is also called qt-x11. That's why the ebuild is called qt-x11 too, and always 
have been. There's no need to shorten names, that just creates confusion :-). 
It's like calling gnome, GDE.

> When/if EClasses gets accepted they won't be restricted to KDE-use
> (right?) and should probably be used for all qt-apps (and probably
> others), meaning that if it's an qt2 app it inherits qt2.eclass and if
> it's an qt3 app it inherits qt3.eclass.
Er, wrong probably. Eclasses will not be used extensively outside kde; that's 
where they are most useful. They might be though. 
But when I said:
- An app being compiled outside ebuilds, non-kde qt apps, and everything else 
that doesn't use eclasses will have to trust that QTDIR is properly set, or 
to set it manually to /usr/lib/qt-x11-$MAJOR_VERSION (no biggie)
I forgot to mention that this is what *all* our ebuilds have had to do so 
far. So we're still far better off.

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Final qt/QTDIR scheme

[Mikael Hallendal]

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]

tis 2001-10-09 klockan 10.10 skrev Dan Armak:
> On Tuesday 09 October 2001 05:19, you wrote:
> > 1) What are the difference between qt-x11 and qt-x11-free.
> qt-x11 comes under the QPL license. This allows to use it freely in 
> developing GPL'd apps, or to purchase a license file, install it and develop 
> commercial ones.
> qt-x11-free allows only the GPL part. It is essentially the same; this 
> license is used e.g. for qt3 betas. I'm not going to add those to portage, I 
> was just giving an example.

Sorry I was unclear, I was wondering what "feature"-changes there were
between the two. Or are they the exact same just distributed with
different licenses?

> > 2) Why is it called qt-x11 and not just 'qt'?
> >    I guess this is because you can build qt-embedded (Is that for
> >    framebuffer)? or perhaps there even is a qt-fb for that. Anyway, my
> >    point is, why not calling "regular" (x11) qt just plain and simple
> >    'qt' and use an extra ending for the others?
> Because qt-x11 is the full, proper name. The source archive/dir, for example, 
> is also called qt-x11. That's why the ebuild is called qt-x11 too, and always 
> have been. There's no need to shorten names, that just creates confusion :-). 
> It's like calling gnome, GDE.

Ok, didn't know the full name was qt-x11 (thought that someone named it
so in portage to make it more clear that it was the x11-build). What
this had to do with GNOME I dunno and why it would ever be called GDE.

> > When/if EClasses gets accepted they won't be restricted to KDE-use
> > (right?) and should probably be used for all qt-apps (and probably
> > others), meaning that if it's an qt2 app it inherits qt2.eclass and if
> > it's an qt3 app it inherits qt3.eclass.
> Er, wrong probably. Eclasses will not be used extensively outside kde; that's 
> where they are most useful. They might be though. 
> But when I said:
> - An app being compiled outside ebuilds, non-kde qt apps, and everything else 
> that doesn't use eclasses will have to trust that QTDIR is properly set, or 
> to set it manually to /usr/lib/qt-x11-$MAJOR_VERSION (no biggie)
> I forgot to mention that this is what *all* our ebuilds have had to do so 
> far. So we're still far better off.

Hmm .. if ebuilds will always just be used for KDE i can't see why it
should be added to portage. I think that if it works fine (which it
seems to do) and is accepted to be part of portage it should be utilized
wherever appropriate and IMHO it sounds like it would be in the examples
discussed above.

Anyway, it's your call, just curious.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Final qt/QTDIR scheme

[Dan Armak]

On Tuesday 09 October 2001 11:43, you wrote:
> Sorry I was unclear, I was wondering what "feature"-changes there were
> between the two. Or are they the exact same just distributed with
> different licenses?
That's right. Up to qt-2.x (not sure which) there were separate packages, 
qt-x11-free, -proffesional and -enterprise. They were unified into qt-x11 
which allows you to install a license file.

> Ok, didn't know the full name was qt-x11 (thought that someone named it
> so in portage to make it more clear that it was the x11-build). What
> this had to do with GNOME I dunno and why it would ever be called GDE.
GDE=Gnome Desktop Environment. I just gave an example of unnecessary 
shortening of names, a bad one :-).

> Hmm .. if ebuilds will always just be used for KDE i can't see why it
> should be added to portage. I think that if it works fine (which it
> seems to do) and is accepted to be part of portage it should be utilized
> wherever appropriate and IMHO it sounds like it would be in the examples
> discussed above.
Of course eclasses can be used verywhere - the more the better - it's just 
that they are most fitted for kde apps. You know best about gnome apps. As 
for pure qt apps, they may profitably inherit e.g. base.eclass. But there are 
very few non-kde qt apps (just 2 or 3 in portage that I can think of). So as 
I said, non-kde use won't be extensive, unless for gnome, about which I don't 
know anything.

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Final qt/QTDIR scheme

[Mikael Hallendal]

tis 2001-10-09 klockan 12.08 skrev Dan Armak:
> On Tuesday 09 October 2001 11:43, you wrote:
> > Sorry I was unclear, I was wondering what "feature"-changes there were
> > between the two. Or are they the exact same just distributed with
> > different licenses?
>
> That's right. Up to qt-2.x (not sure which) there were separate packages, 
> qt-x11-free, -proffesional and -enterprise. They were unified into qt-x11 
> which allows you to install a license file.

Ok, thanks for enlightening me.

> > Ok, didn't know the full name was qt-x11 (thought that someone named it
> > so in portage to make it more clear that it was the x11-build). What
> > this had to do with GNOME I dunno and why it would ever be called GDE.
>
> GDE=Gnome Desktop Environment. I just gave an example of unnecessary 
> shortening of names, a bad one :-).

I understand you meant that but the name is GNOME (which is a
shortening). I thought that the distributed package was named 'qt' and
not qt-<backend>. Just as Gtk+ isn't distributed gtk+-x11, in Gtk+ 2.0
all backends are going into the same tarball and you choose (with
configure-flag) which backend to build.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Final qt/QTDIR scheme -

[Dan Armak]

A question:

How do I define a dependency lilke
3.0.0>x11-libs/qt-x11>=2.3.1-r2
Since qt major versions are api-incompatible, I ned a specific major version 
and a >= for a minor version. Hope I'm making myself clear :-)

I could make two deps:
<x11-libs/qt-x11-3.0.0
>=x11-libs/qt-x11-2.3.1-r2

But the first could be satisfied by 2.2 and the second by 3.0 and I wouldn't 
get the right thing.

I remember reading comments in portage.py about "*" dependencies, when are 
they coming?

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Final qt/QTDIR scheme -

[Mikael Hallendal]

tis 2001-10-09 klockan 16.19 skrev Dan Armak:
> A question:
> 
> How do I define a dependency lilke
> 3.0.0>x11-libs/qt-x11>=2.3.1-r2
> Since qt major versions are api-incompatible, I ned a specific major version 
> and a >= for a minor version. Hope I'm making myself clear :-)

I don't think this is implemented yet.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Final qt/QTDIR scheme - even more questions

[Dan Armak]

Followup:

1. If I do set
DEPEND=">=x11-libs/qt-x11-2.3.1-r1 <x11-libs/qt-x11-3.0.0_beta6"
then, emerge will emerge both these packages, each for the other's 
dependency. It is not smart enouh to see that the deps can be satisfied with 
just one. This is a little off topic, just a note.

2. If I do succeed in making such dependencies, should I (via eclasses) 
require all kde/qt apps to depend on >=qt-x11-2.3.1-r2, which is the current 
revision and is the one that introduces the new QTDIR coexistence scheme? 
Many people probably have qt 2.3.0 or 2.2.3 installed, which in fact fulfill 
the kde dependencies. And if they are forced to go from 2.2.x to 2.3.x 
they'll hvae to recompile all of their kde/qt apps, as the revisions are not 
binary compatible. Of course, with the new scheme, I can easily have 2.2 and 
2.3 revision coexist as well. Should I? That would mean manually emerging the 
new revision of the qt version you already have.

3. The decision has been taken not to include pre-final kde (and qt) versions 
in portage, not even masked. However, many people are likely to be interested 
in the upcoming kde3 ebuilds (kde3-alpha1 was released recently; the ebuilds 
will be ready as soon as this qt thing is finished). On person has already 
asked me for copies of these ebuilds, others may as well. Suggestions for 
placing and distributing them? (Before you suggest it, I don't have a site).

4. A question for the FHS experts: what is the right place to install 
secondary (or equal) copies of KDE? Only one copy can live in /usr, as the 
filenames don't change btween releases. /opt is as i understand for binary 
packages only. Where then? /usr/kde? /usr/local/something? /usr/lib/kde? 
~/kde?

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Final qt/QTDIR scheme - even more questions

[Mikael Hallendal]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

tis 2001-10-09 klockan 17.15 skrev Dan Armak:
> Followup:

Just one thought, imho a solution to this would be to put qt2 in
x11-libs/qt-x11 and qt3 in x11-libs/qt3-x11. This would make sense and
is already used in portage for packages which aren't the same over major
releases (like imlib, glide). I think this scheme would be good in the
way that it won't make users think that qt3 and qt2 can be swapped for
each other.

This would solve the troubles you have here (even if we would like to
have this feature eventually anyway) but in this case I would think that
using different names for the packages would be good (aswell as using
gtk2 or something for Gtk+ 2.0)

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Final qt/QTDIR scheme - solution

[Dan Armak]

Hi all,

Halski's idea, excellent in its simplicity:

To solve the problem of "*" deps, I am going to make several packages.
x11-libs/qt-x11, which will actually be version 2 only so as to not rename an 
existng package.
x11-libs/qtN-x11... which will be version N (3 or later).

This way, dependencies etc. will be very easy.

What the packages will actually install (/etc/env.d/* etc.) will not change.

Please reply with any objections, otherwise I'll do it.

BTW, we'll have qt3-x11-3.0.0, not qt3-x11-1.0.0 like some packages, and not 
qt3-x11-0.0.

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Final qt/QTDIR scheme - solution

[Daniel Robbins]

On Wed, Oct 10, 2001 at 12:15:50AM +0200, Dan Armak wrote:
> Hi all,
> 
> Halski's idea, excellent in its simplicity:
> 
> To solve the problem of "*" deps, I am going to make several packages.
> x11-libs/qt-x11, which will actually be version 2 only so as to not rename an 
> existng package.
> x11-libs/qtN-x11... which will be version N (3 or later).
> 
> This way, dependencies etc. will be very easy.
> 
> What the packages will actually install (/etc/env.d/* etc.) will not change.
> 
> Please reply with any objections, otherwise I'll do it.
> 
> BTW, we'll have qt3-x11-3.0.0, not qt3-x11-1.0.0 like some packages, and not 
> qt3-x11-0.0.

No, don't do this.

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] Final qt/QTDIR scheme - solution

[Mikael Hallendal]

ons 2001-10-10 klockan 01.57 skrev Daniel Robbins:
> On Wed, Oct 10, 2001 at 12:15:50AM +0200, Dan Armak wrote:
> > Hi all,
> > 
> > Halski's idea, excellent in its simplicity:
> > 
> > To solve the problem of "*" deps, I am going to make several packages.
> > x11-libs/qt-x11, which will actually be version 2 only so as to not rename an 
> > existng package.
> > x11-libs/qtN-x11... which will be version N (3 or later).
> > 
> > This way, dependencies etc. will be very easy.
> > 
> > What the packages will actually install (/etc/env.d/* etc.) will not change.
> > 
> > Please reply with any objections, otherwise I'll do it.
> > 
> > BTW, we'll have qt3-x11-3.0.0, not qt3-x11-1.0.0 like some packages, and not 
> > qt3-x11-0.0.
>
> No, don't do this.

Can you please give a reason, this answer is pretty unintersting, imho.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Final qt/QTDIR scheme - solution

[Dan Armak]

> No, don't do this.
I've spoken with Hallski and he says * deps should be ready before qt3-final 
is released (I'm not sure when that'll be, maybe 2 or 4 or 10 weeks for all I 
know). 
So, I'll keep the (uncommitted) qt3 as a new version of the qt-x11 package. 
Just remember qt3 won't be able to go in until * deps are working.


-- 


Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel