from digiKam's description: "Digital photo management application for KDE" If you don't use KDE, why do you want to use a kde-based application without KDE dependencies?

The KDE part doesn't bother me... It's more the mysql. I do use Gnome, but having KDE as deps doesn't matter to me. It doesn't seem quite right that a photo management application (or a DE if you want to extrapolate to KDE) should require a RDBMS, even through an extended chain...?

On 23/11/2009, Gergely Imreh <imrehg@gmail.com> wrote:

Maybe because people have personal preferences, since all these applications are different from each other? So don't be unhappy if they requires dependencies that aren't made for your environment :)

As a comparison, looking at the Ubuntu packaging of digikam: digikam -> kdepimlibs5 -> libakonadiprivate1 (and no mysql only if one installs the whole akonadi-server) Might worth checking out... (libaconadiprivate1: This package contains private libraries used by the Akonadi PIM storage service.) Yes, I looked akonadi's Makefile and we can split akonadi package in akonadi and akonadi-server easy. I'll do some try tomorrow.

Regards -- Andrea `bash` Scarpino Arch Linux Developer

2009/11/23 Andrea Scarpino <andrea@archlinux.org>:

On 23/11/2009, Gergely Imreh <imrehg@gmail.com> wrote:

...

Maybe because people have personal preferences, since all these applications are different from each other? So don't be unhappy if they requires dependencies that aren't made for your environment :)

I'm sorry, to me this reads as one have two choice: accept or leave. But that's not the case, as you yourself noticed that the packaging can be made more rational. It's open source, people can do try fixing things / suggesting fixes instead of just accepting the status quo. I think the original issue can be cast into a broader topic: (without giving any references, because I don't have any from the top of my head right now) I encounter quite a few packages that have dependencies down the chain that don't seem to be related to the original package. This seems to be a general open source issue. It's great to have libraries to divide the task into smaller pieces and reuse whatever possible, but projects seem to be less effectivee dividing between "depends" and "optdepends". Sometimes it's an upstream issue, sometimes it's packaging. With more practice and more eyes checking things out it will be better. Anyway, this is just an observation, Arch seems to do quite well in general (thanks Maintainers:). I'll look around the repos again and might come up for some more repackaging ideas for the next bug squashing day or something...

...

As a comparison, looking at the Ubuntu packaging of digikam: digikam -> kdepimlibs5 -> libakonadiprivate1 (and no mysql only if one installs the whole akonadi-server) Might worth checking out... (libaconadiprivate1: This package contains private libraries used by the Akonadi PIM storage service.) Yes, I looked akonadi's Makefile and we can split akonadi package in akonadi and akonadi-server easy. I'll do some try tomorrow.

That sounds great! Cheers! :) Greg

2009/11/23, Heiko Baums <lists@baums-on-web.de>:

I'm running a Linux only system, so I don't need samba. Wouldn't it be possible to move smbclient from depends to optdepends in the affected packages?

Why do you don't fill a bug report for those packages? -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

Am Mon, 23 Nov 2009 12:54:49 +0100 schrieb Tobias Powalowski <t.powa@gmx.de>:

Some depends are made for convenience, you can build the packages with ABS without those depends, if they don't stop the program from starting remove them and add then to ignore array in pacman.conf.

But if I wanted to compile everything manually I would have stayed with Gentoo. ;-) Heiko

On Mon, Nov 23, 2009 at 02:31:37PM +0200, Ionut Biru wrote:

On 11/23/2009 02:24 PM, Heiko Baums wrote:

...

Am Mon, 23 Nov 2009 12:54:49 +0100 schrieb Tobias Powalowski<t.powa@gmx.de>:

...

Some depends are made for convenience, you can build the packages with ABS without those depends, if they don't stop the program from starting remove them and add then to ignore array in pacman.conf.

But if I wanted to compile everything manually I would have stayed with Gentoo. ;-)

Heiko

like i said previous better to have that feature. Removing that feature just because _you_ don't use and _you_ want to have minimal packages is not the way.

The only way is to get the build for those packages with ABS, remove smbclient from your system and recompile those packages. Is simple and is automatically thought makepkg.

-- Ionut

I don't want to flame, but that's why I recently moved to Gentoo. Arch is one of the best distros I've used, but when you use a (primarily) binary distro, the number of choices you have is reduced. I don't blame the devs, though. They must make packages that appeal to a large number of users and Arch ends up with packages with a big number of dependencies. If you think about it, using a little bit more of disk space isn't a big problem compared to the problem some people would have if the default packages weren't compiled with these extra dependencies, because they would have to compile their own packages, defeating the reason to use a binary-based distro. I know, Arch has ABS, which is a great improvement compared to others binary-based distros, but it's still not perfect. Pacman doens't look for custom PKGBUILDs and automatically create the new packages based on them, and I guess it won't. Pacman wasn't meant to do that. You can make scripts based on pacman and ABS that will do this (I've made one shortly before changing distros), but then I realised I don't know all the ./configure options a package has, and I find documentation on this a little scarce. Using the 'USE' flags with emerge is much simpler in this aspect.

Am Mon, 23 Nov 2009 11:17:13 -0200 schrieb André Ramaciotti da Silva <andre.ramaciotti@gmail.com>:

I don't want to flame, but that's why I recently moved to Gentoo. Arch is one of the best distros I've used, but when you use a (primarily) binary distro, the number of choices you have is reduced.

I don't blame the devs, though. They must make packages that appeal to a large number of users and Arch ends up with packages with a big number of dependencies. If you think about it, using a little bit more of disk space isn't a big problem compared to the problem some people would have if the default packages weren't compiled with these extra dependencies, because they would have to compile their own packages, defeating the reason to use a binary-based distro.

I know, Arch has ABS, which is a great improvement compared to others binary-based distros, but it's still not perfect. Pacman doens't look for custom PKGBUILDs and automatically create the new packages based on them, and I guess it won't. Pacman wasn't meant to do that.

You can make scripts based on pacman and ABS that will do this (I've made one shortly before changing distros), but then I realised I don't know all the ./configure options a package has, and I find documentation on this a little scarce. Using the 'USE' flags with emerge is much simpler in this aspect.

I don't think that you will stay too long with Gentoo. ;-) It is right that you can reduce the dependencies a bit and that you are more flexible by setting USE flags. As far as I recall the difference between Gentoo and Arch Linux regarding the disk space is not significant if there's a difference at all, but you will need a lot more temporary disk space for compiling and it takes several days to compile the whole system and every update takes much longer than on Arch Linux. So I think "wasting" a bit disk space for dependencies which aren't needed is better than wasting too much time for compiling the whole system. That's why I switched from Gentoo to Arch Linux a while ago. On Arch Linux you still have the same control over the installed packages as you have on Gentoo. Don't overvalue the USE flags. There's optdepends to reduce the dependencies a bit as long as a dependency can be made optionally. Otherwise more comfort for the common users is better I think. And pacman and ABS are good as they are. There's still the NoUpgrade option in pacman.conf if you build a package from ABS. Heiko

Am Mon, 23 Nov 2009 12:16:46 -0200 schrieb André Ramaciotti da Silva <andre.ramaciotti@gmail.com>:

I know, I know, they always come back. :P My Arch installation is still in my HD, just in case.

About disk usage, don't forget that arch keeps a cache of downloaded packages. So I don't think Gentoo is in disadvantage here. My installation uses 1GB less than Arch (both have basically the same packages). It may not sound like a lot, thinking of the size most HD have nowadays, but it's a 20% improvement.

But you can delete the cached packages in Arch (pacman -Sc or pacman -Scc). ;-) If this is useful is a different question.

I don't think compiling takes that much. If you're in a hurry, then yes, it'll seem like forever. I installed in a weekend, basically the same time I took to install Arch (because I install some packages, then I remember of others, then others...). But it wasn't 48h compiling, it was way, way less.

On my old i686 1,3 GHz CPU with 1 GB RAM it took me a week to compile and install the complete Gentoo system inkl. Xorg, KDE, OpenOffice etc. while I only need 1 or 2 days for Arch. And KDE alone took me 1 day and OpenOffice 12 hours. I did this several years until I had enough of this waste of time and found Arch Linux. Even if compiling only takes 48 hours. Installing it on Arch takes only a few seconds or maximum a few minutes. And compiling uses more ressources and thus more energy.

I agree that with Arch you still have control over your packages, but USE flags make it easier. Somebody already went into the ./configure of all packages and put it in an easier way to do it. If programs could talk, emerge would be like: - I want my mplayer with samba and lirc support. - OK, I'll configure it this way, but then you also need to install this and this packages. While pacman would be something like: - I want my mplayer without samba support. - Wakka wakka wakka. Make a custom PKGBUILD then, wakka wakka.

The problem is that in my experience most USE flags are set to get a more comfortable system, see the lot of USE flags for support for MP3, Ogg/Vorbis etc. Who wants a media player without MP3 or Ogg/Vorbis support? Only a few USE flags make really sense. The whole USE flag stuff can also get quite complex. And then once in a while they change the names of the USE flags without changing their function or they remove USE flags all without announcement. So after a while your make.conf (or what was the name of the file) will get bigger and bigger and even more complex. On Arch Linux you are not quite as flexible as in Gentoo but it's much more comfortable. Portage is getting slower and slower from time to time. There's no portage overlay like AUR where a user can easily upload ebuilds. To be able to upload to Sunrise you need to be a dev or something like a TU and you first have to file a bug report and attach your ebuild. If your lucky your ebuild will be added to Sunrise a few weeks later. If your not so lucky every user who want to install this package needs to download this ebuild manually from bugzilla for years. And due to many undocumented ebuild functions and non-expressive variable names and a more complex directory structure for the build system it's much more difficult writing an ebuild than a PKGBUILD. I don't want to say that Gentoo is a bad distro (it's indeed beside Arch one of the best) but it takes more time and is more complicated than Arch without a big advantage.

And finally, yes, there are optdeps, but pacman don't handle them as nicely it handles obligatory dependencies. If I install an optdep as an explicit installed package, when I uninstall the other package, the optdep will stay in my system. If I install it as a dependency, pacman will list it as an unnecessary dependency when I run pacman -Qdt.

Well, this is a point which I'm missing, too, on Arch. This should indeed be fixed in pacman. Heiko

On Mon, Nov 23, 2009 at 04:06:34PM +0100, Heiko Baums wrote:

Am Mon, 23 Nov 2009 12:16:46 -0200 schrieb André Ramaciotti da Silva <andre.ramaciotti@gmail.com>:

...

I know, I know, they always come back. :P My Arch installation is still in my HD, just in case.

About disk usage, don't forget that arch keeps a cache of downloaded packages. So I don't think Gentoo is in disadvantage here. My installation uses 1GB less than Arch (both have basically the same packages). It may not sound like a lot, thinking of the size most HD have nowadays, but it's a 20% improvement.

But you can delete the cached packages in Arch (pacman -Sc or pacman -Scc). ;-) If this is useful is a different question.

And you can delete the sources in Gentoo. Both distros are pretty OK here.

...

I don't think compiling takes that much. If you're in a hurry, then yes, it'll seem like forever. I installed in a weekend, basically the same time I took to install Arch (because I install some packages, then I remember of others, then others...). But it wasn't 48h compiling, it was way, way less.

On my old i686 1,3 GHz CPU with 1 GB RAM it took me a week to compile and install the complete Gentoo system inkl. Xorg, KDE, OpenOffice etc. while I only need 1 or 2 days for Arch. And KDE alone took me 1 day and OpenOffice 12 hours. I did this several years until I had enough of this waste of time and found Arch Linux.

Even if compiling only takes 48 hours. Installing it on Arch takes only a few seconds or maximum a few minutes. And compiling uses more ressources and thus more energy.

Indeed, if I used KDE, I wouldn't use Gentoo. OTOH, Gentoo offers binary packages of OpenOffice, Firefox and some other apps. However, from what emerge tells me, firefox sources are one third the size of firefox-bin. As Brazil isn't famous for its ultra-fast broadband, I can imagine certain cases that compiling is faster. I agree with most of what you wrote, and I don't have the slightest idea of how maintaining a Gentoo system in the long run is. I'm just trying it and I like it so far, but keep in mind I've been using it for only one week. This wasn't the first time I thought of trying Gentoo, so I installed it to see how it is or I would be always thinking about it. When I get tired of compiling, I'll go back to Arch with a better idea of its strengths. :)

On Mon, 23 Nov 2009 14:49:19 +0100 Heiko Baums <lists@baums-on-web.de> wrote:

Am Mon, 23 Nov 2009 11:17:13 -0200 schrieb André Ramaciotti da Silva <andre.ramaciotti@gmail.com>:

...

I don't want to flame, but that's why I recently moved to Gentoo. Arch is one of the best distros I've used, but when you use a (primarily) binary distro, the number of choices you have is reduced.

I don't blame the devs, though. They must make packages that appeal to a large number of users and Arch ends up with packages with a big number of dependencies. If you think about it, using a little bit more of disk space isn't a big problem compared to the problem some people would have if the default packages weren't compiled with these extra dependencies, because they would have to compile their own packages, defeating the reason to use a binary-based distro.

I know, Arch has ABS, which is a great improvement compared to others binary-based distros, but it's still not perfect. Pacman doens't look for custom PKGBUILDs and automatically create the new packages based on them, and I guess it won't. Pacman wasn't meant to do that.

You can make scripts based on pacman and ABS that will do this (I've made one shortly before changing distros), but then I realised I don't know all the ./configure options a package has, and I find documentation on this a little scarce. Using the 'USE' flags with emerge is much simpler in this aspect.

I don't think that you will stay too long with Gentoo. ;-)

It is right that you can reduce the dependencies a bit and that you are more flexible by setting USE flags. As far as I recall the difference between Gentoo and Arch Linux regarding the disk space is not significant if there's a difference at all, but you will need a lot more temporary disk space for compiling and it takes several days to compile the whole system and every update takes much longer than on Arch Linux. So I think "wasting" a bit disk space for dependencies which aren't needed is better than wasting too much time for compiling the whole system. That's why I switched from Gentoo to Arch Linux a while ago. On Arch Linux you still have the same control over the installed packages as you have on Gentoo. Don't overvalue the USE flags.

There's optdepends to reduce the dependencies a bit as long as a dependency can be made optionally. Otherwise more comfort for the common users is better I think.

And pacman and ABS are good as they are. There's still the NoUpgrade option in pacman.conf if you build a package from ABS.

Heiko

But NoUpgrade isn't really a solution, because you have to do the work manually over and over again whether you use NoUpgrade or not.

On Mon, 2009-11-23 at 16:19 -0700, Brendan Long wrote: <big snip>

I'm actually using Arch primarily because it's so little work to make your own packages (I realized that no distro is going to have every package I want, although Arch has most of them). In most cases building the next version of a package consists of changing the package number and then running makepkg. It would be nice if there was a script that attempted to do this on updates and then informed you if it didn't work. -Brendan

While a nice idea (perhaps suggest it as a feature to pakthan or yaourt?), I don't see how such a script would know that there IS a new version of a package if the repos aren't updated. Unless you're actually referring to marking some packages as 'I compiled this myself, please do that again for me when the repo updates'? In the latter case, you could probably just write a simple bash script to grep/sed the relevant numbers and --configure options, I do that to mirror kernel26-ice to kernel26-rt-ice.

On Tue, 2009-11-24 at 21:56 +0800, Gergely Imreh wrote:

2009/11/24 Ng Oon-Ee <ngoonee@gmail.com>:

...

On Mon, 2009-11-23 at 16:19 -0700, Brendan Long wrote: <big snip>

...

I'm actually using Arch primarily because it's so little work to make your own packages (I realized that no distro is going to have every package I want, although Arch has most of them). In most cases building the next version of a package consists of changing the package number and then running makepkg. It would be nice if there was a script that attempted to do this on updates and then informed you if it didn't work. -Brendan

While a nice idea (perhaps suggest it as a feature to pakthan or yaourt?), I don't see how such a script would know that there IS a new version of a package if the repos aren't updated. Unless you're actually referring to marking some packages as 'I compiled this myself, please do that again for me when the repo updates'?

In the latter case, you could probably just write a simple bash script to grep/sed the relevant numbers and --configure options, I do that to mirror kernel26-ice to kernel26-rt-ice.

Similar as it is done in Debian (and Ubuntu) with the debian/watch files? http://wiki.debian.org/DEHS

Cheers, Greg

Huh, that's pretty cool. Just knowing when Arch has a new version out and trying to recompile my custom package would be good enough for me though :) -Brendan

Am Mon, 23 Nov 2009 14:31:37 +0200 schrieb Ionut Biru <biru.ionut@gmail.com>:

like i said previous better to have that feature. Removing that feature just because _you_ don't use and _you_ want to have minimal packages is not the way.

I agree with you. It was just a question. As it's not possible to put smbclient to optdepends it's ok as it is. Heiko

Le Mon, 23 Nov 2009 04:46:44 -0800, Giovanni Scafora <giovanni@archlinux.org> a écrit :

mplayer != everything

Agreed, and mplayer is meant to be compiled on the machine on which it is used. No set of dependencies will ever make all the users happy. You should use one of the packages on the AUR for that, with Yaourt if you are too lazy to update it yourself by hand. -- catwell

On 11/23/2009 01:49 PM, Heiko Baums wrote:

Am Mon, 23 Nov 2009 11:30:50 +0800 schrieb Gergely Imreh<imrehg@gmail.com>:

...

Anyway, this is just an observation, Arch seems to do quite well in general (thanks Maintainers:). I'll look around the repos again and might come up for some more repackaging ideas for the next bug squashing day or something...

I have another suggestion.

Currently smbclient is installed as a dependecy for gnome-vfs, kdebase-runtime, mplayer and vlc likely among others.

I'm running a Linux only system, so I don't need samba. Wouldn't it be possible to move smbclient from depends to optdepends in the affected packages?

Heiko

can't be an optdepends. pacman -Rd smbclient mplayer mplayer: error while loading shared libraries: libsmbclient.so.0: cannot open shared object file: No such file or directory smbclient is kinda important for those packages. removing such dependency will make a lot of users unhappy. -- Ionut