2 Feb
2012
2 Feb
'12
9:52 a.m.
Hey,
On Wed, February 1, 2012 16:57, E. Liddell wrote:
I agree, lets stick with the default
place. I do have an ebuild for
qt-3.3.8d and removed all patches that I didn't need to get it working.
For some i couldn't find the bug-id since it was long gone on
bugs.gentoo.org or didn't apply against the latest version.
I'm a bit worried about it being too similar to kde-, though. Doesn't
matter
for the eclasses or directories, but for stuff end-users are going to have
to
type on a regular basis, I'd like to be as distinct as possible. Adding new
categories is easy, just create the folder-structure and
portage will complain that you need to add your own categories into
profiles/categories.;)
About it being too similar... unless we change the actual ebuild-name
(like kdebase-startkde -> tdebase-starttde) they have to emerge it via
'emerge trinity-base/kdebase-startkde' since the package exists in another
category as well).
So how far do you wanna go with the renaming?
Ok, but lets try to get the
cmake-parts in there first and worry about
that later. Maybe then we have a tqt3 and just have to ask Serghei.;)
PS: I hope i will have the cleaned eclasses and dependencies in git until
Saturday since i am currently quite busy with work etc.. but i want to get
this finally working on gentoo/funtoo and will have to take my time.
BTW i am not really running gentoo but funtoo, so i might ask there for
some additional help. It's easier to ask for some help there since even
D.Robbins is idling there sometimes. And who else knows portage better?;)
greetings,
roman
--
The dev manual indicates that the Gentoo dev team
considers the filesystem
standard as more of a guideline than an absolute, but since we both think
/usr/tde/[version] is good we might as well go with that.
Ok, /usr/tde it is then.
Mhh my guess
is we need to put qt3 in a seperate directory (or should be
keep it in /usr/qt/3 ?) otherwise there will be tons of complications.
With the next version, we should be able to go to /usr/tqt, but moving to
there with 3.5.13 might be a bit premature. Okay, so the first step is to get tde-base, its
dependancies, and the
eclasses (I think cmake only uses -functions and maybe qt3) in
there. Then ebuilds for the other stuff that's already been moved
to cmake. After that, we can look at the rest.
Yes, i am currently trying to get
the dependencies in-line so they can be
used by anyone. Hal is still required right?
In kde-*.eclass i think it might be wise to comment/remove all functions
und reenable the ones that are still needed for the remaining non-cmake
ebuilds on a as-needed basis.
how adding whole categories works. I'm also
looking at changing the
names of the eclasses (kde-functions -> tde-functions or
trinity-functions,
etc.)
Definitly! I would go with tde-* it's less typing.;) Yes, i think
there is at least a cmake-option or variable in the eclass
that specifies the moc-location or the kde-prefix to use.
I'm more worried about the non-cmake packages in that regard, but
they're screwed up anyway. Since no one on the trinity-dev list seems
interested in helping me sort out the linker problem that seems to exist
in half the packages, I may need to go to gentoo-dev for help, which is
something I'm not looking forward to. :(