You are not logged in.
Pages: 1
I am a Gentoo user. In portage kde packages are splited out. For example:
I can install "ksnapshot" or "kpdf" without pulling whole kdegraphics package with a lot of other tools for graphics. In Arch Linux i have to install whole kdegraphics package to get for example kpdf. It also will install kooka, kuickshow, kolourpaint and lots of other programs that I don't need. So it would be nice if I could install separate KDE programs without complete sets.
"god@heaven$ emerge world"
~ Genesis on Gentoo
Offline
please search the wiki, you will find there answers
Offline
its not a new idea, sorry.
Offline
its not a new idea, sorry.
not in Extra also
Offline
lock please!
I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell
Offline
i do not see where we always say no. please see the wiki, search the forums or browse the mailinglist archives. there's been one hell of a discussion about this everywhere.
I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell
Offline
kth5 wrote:lock please!
This seems to be the answer to everything in Arch ... lock it and shut it up. :?
s/cynicalme 8)
Oh puh-lease...
Offline
This seems to be the answer to everything in Arch ... lock it and shut it up. :?
Nah, we just get really really bored discussing the same things to death over and over. We're mostly of a hacker mindset... attention defecit is common, we like to work on new problems, not rehash old. That's why we're starving open source developers instead of well-paid microsoft programmers.
Dusty
Offline
Short answer: Splitting the KDE packages would be against The Arch Way. As long as the KDE team releases big packages (kdelibs, kdebase, etc), Arch will use the same release scheme for KDE.
Offline
It would be very hard for me looking for a new distro if the KDE (or whatever) packages in Arch get split...
Microshaft delenda est
Offline
AFAIK KDE developers want to split KDE4 into more packages. Am I wrong?
to live is to die
Offline
AFAIK KDE developers want to split KDE4 into more packages. Am I wrong?
I thought there were plans, but I believe they haven't decided on it, yet.
Offline
AFAIK KDE developers want to split KDE4 into more packages. Am I wrong?
extra/kdebase 3.5.1-4
KDE Base Programs.
Aint KDE4 yet.
obsrv: That's all nice and whatever that gentoo have split packages, but they also dont update as frequently as Arch do. They also dont need to maintain hundreds of binary packages as well as the ebuilds. It would take an inordinate amount of effort to split KDE up, for no benefit. Any computer that can run KDE as it is now even half decently has more than enough hdd space for the extra text editor or silly image editor.
iphitus
Offline
I don't want to have KDE packages split. Can I have what I want?
You can please some of the people some of the time...
Offline
I know I'm boring, and yes, I know I'm bringing the same topic on and on, but I think optional dependencies should be introduced into pacman.
I mean, the problem with KDE packages and almost any other big packes is that their dependencies are immense. And yes, iphitus, while I don't mind having 3 text editors or image editors installed, I do mind having to install loads of dependencies I don't need.
I already made a feature request:
http://bugs.archlinux.org/task/3840
Offline
I agree. The problem is not in having some unneeded packages but in having useless dependencies that are, in fact, optional, but are installed and upgraded by Pacman with upgrade of main package.
Of course, such dependency system as Genott's USE-flags is not possible with binary packages, but some improvements could be done. FS#3840 is good idea, IMO.
to live is to die
Offline
I agree. The problem is not in having some unneeded packages but in having useless dependencies that are, in fact, optional, but are installed and upgraded by Pacman with upgrade of main package.
Of course, such dependency system as Genott's USE-flags is not possible with binary packages, but some improvements could be done. FS#3840 is good idea, IMO.
This has happened (at least to a certain degree) allready - for example file-roller supports various file formats, but only if you install different commandline tools (it doesn't depend on them).
Offline
Thought I'd look into helping out, some day soon, by splitting out KDE packages -- or at least look into what amount of work it might be (before jumping in, blind). My first step was to write to Dan Armak, former Gentoo KDE maintanier. Since he sent such an informative reply, I wanted to post it here as a way to 1) preserve it (or back it up); and 2) to share.
Here's my inquiry:
Dan,
Am interested in splitting the current "monolithic" packages for the
distro Arch Linux. I saw your e-mail address on the Gentoo wiki and
wanted to ask: Do you have any, say, shell scripts that help you do
this for Gentoo? If so, would you be willing to share them? Could
you share any other tips on how to do this task?Thanks,
Here's Dan's informative reply:
Hello,
First off, I quit Gentoo development a few months ago. danarmak@OBSCURED1
will stop receiving mail sometime soon, so please mail me at
danarmak@OBSCURED2 and fix the link in that wiki if you can.About splitting packages: I don't have any scripts that'd help you (what we
have is ebuild-specific), but the info we've gathered while creating the
split KDE ebuilds will probably be useful.When splitting the ebuilds, we first had to list the split packages mapped to
each monolithic package. Some of the toplevel dirs in the monolithic tarball
are upstream-deprecated, some split packages include more than one top-level
dir, etc.Then we had to map out the inter-dependencies between split packages. This
include many build-time deps that are not actually runtime deps, because
upstream apparently isn't used to the idea of selectively compiling only one
app; distros which aren't source-based like Gentoo compile everything and
then just package in pieces.And finally we had to check which of the deps (and reverse deps) the
monolithic kdepim package had belonged to which derived split ebuild.I've never used Arch Linux; will you need to take per-split-package compile
time deps into account? If you do, this will probably be the most tricky
part. Some apps rely on libraries being built in-tree, and not just present
in $DESTDIR. So to build e.g. kmail, you need to take some 9 libraries from
kdepim, which are installed by other packages, and copy or symlink the
installed .so and .la files back into you build tree. Similar things happen
with other buildtime-generated stuff.Luckily you can gather all this info from the Gentoo ebuilds (viewcvs:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/).eclass/kde-functions.eclass defines the KDE_DERIVATION_MAP variable. This maps
split packages to monolithic ones, so you can see what all there is. Then you
can look at the ebuilds for each split package.The global variables starting with KM (for kde-meta-) in each ebuild are
instructions to the split ebuild build system. There's a brief explanation of
what they do in eclass/kde-meta.eclass (comment block starting with "Set the
following variables"). So looking at e.g. the kmail ebuild
(kde-base/kmail/kmail-3.5.4.ebuild) you'll see:DEPEND=, RDEPEND=: normal build- and run-time dependencies.
KMCOPYLIB: as described above, these libs are copied from the live system to
the build tree.
KMEXTRACTONLY: these extra dirs are extracted (from the kdepim tarball) but
are not compiled. The kmail compilation accesses non-installed headers there
or whatever.
KMCOMPILEONLY: this dir is extracted and compiled, but not installed. Probably
builds e.g. a static library included by kmail.
KMEXTRA: stuff that's built and installed - basically pieces of kmail outside
the main kdepim/kmail directory.HTH. Feel free to ask for more info. You can also ask the remaining Gentoo KDE
packagers at kde@OBSCURED3.--
Dan Armak
Also want to add: No, I don't have a clue what I'm getting myself into. Never stopped me before. 8)
EDIT: Obscured e-mail addresses to thwart the spam-bots.
.
Offline
ahh good luck soloport!
KISS = "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." - Albert Einstein
Offline
Yeah good luck (sarcasm). Packages that now depend on "kdebase" are going to have to depend on 5-6 specific kde libs when kdebase is split up. In fact, if you really want this done, you should talk to the KDE people. Arch will never do this.
Offline
If there is someone which want to make kde splited pkgs i can help him and we can make a little unofficial repo with most important kde pkgs.For contact use PM.
Offline
Awhile back I split most every kde package.. I was going to release a repo for it, but as i dont use kde anymore, i didnt have mch incentive to keep it up. Anyhow, since enough people seem to be wanting this, i'd be willing to update dependencies and do it again.
Originally i did split up base, but along with what phrakture mentioned above, the fact that personally i've found most everything in kdebase to be somewhat beneficial to a kde install. And the fact that it's a bit of a pain, i'd be only splitting the extra packages, such as games, graphics, multimedia, pim etc. Everything but base.
If everyone who would like this is cool with that, i'll check out what has been updated since my old pkgbuilds and get to putting them back out.
Offline
That would be great! Maybe I can help as well.
Offline
go! go!
KISS = "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." - Albert Einstein
Offline
Yeah good luck (sarcasm). Packages that now depend on "kdebase" are going to have to depend on 5-6 specific kde libs when kdebase is split up. In fact, if you really want this done, you should talk to the KDE people. Arch will never do this.
Kdebase and kdelibs aren't the problem and should not be split.
But some parts of kdeadmin like the sysvinit tool and the network configuration part should really be disabled. They really don't work in arch and can possibly ruin the system.
Offline
Pages: 1