| 1 |
tis 2001-10-09 klockan 10.10 skrev Dan Armak: |
| 2 |
> On Tuesday 09 October 2001 05:19, you wrote: |
| 3 |
> > 1) What are the difference between qt-x11 and qt-x11-free. |
| 4 |
> qt-x11 comes under the QPL license. This allows to use it freely in |
| 5 |
> developing GPL'd apps, or to purchase a license file, install it and develop |
| 6 |
> commercial ones. |
| 7 |
> qt-x11-free allows only the GPL part. It is essentially the same; this |
| 8 |
> license is used e.g. for qt3 betas. I'm not going to add those to portage, I |
| 9 |
> was just giving an example. |
| 10 |
|
| 11 |
Sorry I was unclear, I was wondering what "feature"-changes there were |
| 12 |
between the two. Or are they the exact same just distributed with |
| 13 |
different licenses? |
| 14 |
|
| 15 |
> > 2) Why is it called qt-x11 and not just 'qt'? |
| 16 |
> > I guess this is because you can build qt-embedded (Is that for |
| 17 |
> > framebuffer)? or perhaps there even is a qt-fb for that. Anyway, my |
| 18 |
> > point is, why not calling "regular" (x11) qt just plain and simple |
| 19 |
> > 'qt' and use an extra ending for the others? |
| 20 |
> Because qt-x11 is the full, proper name. The source archive/dir, for example, |
| 21 |
> is also called qt-x11. That's why the ebuild is called qt-x11 too, and always |
| 22 |
> have been. There's no need to shorten names, that just creates confusion :-). |
| 23 |
> It's like calling gnome, GDE. |
| 24 |
|
| 25 |
Ok, didn't know the full name was qt-x11 (thought that someone named it |
| 26 |
so in portage to make it more clear that it was the x11-build). What |
| 27 |
this had to do with GNOME I dunno and why it would ever be called GDE. |
| 28 |
|
| 29 |
> > When/if EClasses gets accepted they won't be restricted to KDE-use |
| 30 |
> > (right?) and should probably be used for all qt-apps (and probably |
| 31 |
> > others), meaning that if it's an qt2 app it inherits qt2.eclass and if |
| 32 |
> > it's an qt3 app it inherits qt3.eclass. |
| 33 |
> Er, wrong probably. Eclasses will not be used extensively outside kde; that's |
| 34 |
> where they are most useful. They might be though. |
| 35 |
> But when I said: |
| 36 |
> - An app being compiled outside ebuilds, non-kde qt apps, and everything else |
| 37 |
> that doesn't use eclasses will have to trust that QTDIR is properly set, or |
| 38 |
> to set it manually to /usr/lib/qt-x11-$MAJOR_VERSION (no biggie) |
| 39 |
> I forgot to mention that this is what *all* our ebuilds have had to do so |
| 40 |
> far. So we're still far better off. |
| 41 |
|
| 42 |
Hmm .. if ebuilds will always just be used for KDE i can't see why it |
| 43 |
should be added to portage. I think that if it works fine (which it |
| 44 |
seems to do) and is accepted to be part of portage it should be utilized |
| 45 |
wherever appropriate and IMHO it sounds like it would be in the examples |
| 46 |
discussed above. |
| 47 |
|
| 48 |
Anyway, it's your call, just curious. |
| 49 |
|
| 50 |
Regards, |
| 51 |
Mikael Hallendal |
| 52 |
|
| 53 |
-- |
| 54 |
|
| 55 |
Mikael Hallendal |
| 56 |
Gentoo Linux Developer, Desktop Team Leader |
| 57 |
CodeFactory AB, Stockholm, Sweden |
Archives