Amarok 2.6.0

[hariskar]

Is there any easy way to install Amarok 2.6.0?
What is the procedure? I saw so many packages and dependencies in download page.
Thank you!

[craigevil]

Sure run Debian sid.

Then it is a simple:
apt-get install amarok

$ apt-cache policy amarok
amarok:
Installed: (none)
Candidate: 2.6.0-1
Version table:
2.6.0-1 0
500 http://ftp.us.debian.org/debian/ unstable/main i386 Packages

Other than that you might check the mepis repos, but since it is essentially a KDE/QT app you will need all of the dependencies installed no matter how you install it.

[hariskar]

Thank you!
Should I avoid this version because it is sid or it's not so unstable?
Why isn't a more recent stable version then 2.3?

[kedaha]

There's a more recent version, 2.4.1-1 in squeeze-backports:

Code: Select all

$ apt-cache policy amarok
amarok:
  Installed: (none)
  Candidate: 2.3.1-1
  Version table:
     2.4.1-1~bpo60+1 0
        100 http://backports.debian.org/debian-backports/ squeeze-backports/main amd64 Packages
     2.3.1-1 0
        990 http://ftp.caliu.cat/debian/ squeeze/main amd64 Packages


I tried to build amarok 2.6.0 with pbuilder in squeeze but it failed because libcups2 amd64 1.5.3-2 and libcurl3_7.27.0-1_amd64.deb were not found in sid.

[hariskar]

Why is Amarok not quickly updated for Debian? In most other distributions current version is 2.5.0 and in some it can easily be updated to 2.6.0. In windows current stable version is 2.6.0.

[dilberts_left_nut]

Because squeeze is stable (does not change).
There are no version updates.

[kedaha]

You'll find the answer in: debian-faq/ch-choosing.en.html:

...you might find that stable contains old versions of packages. However, they have been tested in and out. One can confidently say that the packages do not have any known severe bugs, security holes etc., in them. The packages in stable integrate seamlessly with other stable packages.

Getting the latest packages to work in the current stable release requires backporting, and this takes some time, skill and effort by unpaid volunteers. Sometimes it's easy to backport a package but other times it's not so easy.

On the other hand, packages in testing or unstable can have hidden bugs, security holes etc., Moreover, some packages in testing and unstable might not be working as intended. Usually people working on a single desktop prefer having the latest and most modern set of packages. Unstable is the solution for this group of people.

As you can see, stability and novelty are two opposing ends of the spectrum. If stability is required: install stable distribution. If you want to work with the latest packages, then install unstable.

So if you want quick access to the newest package, run sid:
But please see life_with_eternal_upgrades:

It takes no more than simply setting the distribution string in the "/etc/apt/sources.list" to the suite name: "testing" or "unstable"; or the codename: "wheezy" or "sid". This makes you live the life of eternal upgrades.

The use of testing or unstable is a lot of fun but comes with some risks. Even though the unstable suite of Debian system looks very stable for most of the times, there have been some package problems on the testing and unstable suite of Debian system and a few of them were not so trivial to resolve. It may be quite painful for you. Sometimes, you may have a broken package or missing functionality for a few weeks.

So one solution proposed by the author of The Debian Reference is:

Make the system dual bootable by installing the stable suite of Debian system to another partition

[hariskar]

Do I have to install Debian sid to install Amarok 2.6? Can't I install it on Debian 6.0.6?

[craigevil]

Do I have to install Debian sid to install Amarok 2.6? Can't I install it on Debian 6.0.6?

Short answer No.

Long answer you may be able to backport it.
Howto get newer package versions for Debian Stable
https://www.linuxquestions.org/question ... ble-34611/

How do I backport a sid package to testing or stable?

Install the Debian source (and the development tools, especially debhelper, devscripts, and build-essential), and then build the package.

Step by step:
Following the same steps you used to add the backports repo:
add a deb-src line for sid to your sources.list
deb-src http://ftp.us.debian.org/debian/ unstable main contrib non-free

apt-get update

apt-get build-dep PACKAGE_NAME

apt-get -b source PACKAGE_NAME

The resulting debs should be in the current directory and can be installed with dpkg -i the.deb or gdebi if you have it installed.

[stevepusser]

It can be backported, but you will need a backported version of KDE 4.6 and at least a backported libtag1 1.7. See here for requirements: http://amarok.kde.org/wiki/Requirements

Sid's version has a patch to enable building with KDE 4.7+ which probably will need disabling to build with KDE 4.6. (/debian/patches/series)

You can get a backported KDE 4.6 from the debian-desktop repo, but you'll have to backport libtag1 yourself from wheezy, or get it from the MEPIS community repo, or at least get the sources from there, since I probably had to undo the multiarch changes when I backported it there, and it's pretty complicated to explain how to do that.

http://main.mepis-deb.org/mepiscr/testr ... /t/taglib/

[thegeko]

This is a serious drawback of debian packaging. In stable version you get 2 years (!!) old packages. OK, I know, I should run testing/unstable if I want new packages. Actually, I should run unstable, because packages in testing are still somewhat old.

BUT, the excuse that stable is bug free, is a MYTH. Oftentimes I run into a bug, google it, and find a tracker which has been solved for a year or two. I don't mean something stupid, I mean serious bugs. For instance right now, amarok plays each song twice in a row on random mode, I mean if this is not serious bug, then what is?? Thus it seems to me, old versions in stable carry their old bugs solved long ago. From this point of view I don't see many advantages of stable. I can only suppose, when someone says bug-free in debian community, he means security-bug-free. I cannot confirm or deny this, but then stable is only usable on production servers (but still only if you don't require state-of-art newest tools).

Sad thing is, with this in mind, I decided to upgrade my stable box to testing. Ended up loosing a day trying to resolve dependency problems. Turned out extremely complicated, and had to do a clean install in the end. Thus usual point "simply upgrade to testing" is not that simple and does not stand. The reason is that upgrade process is the last thing that is tested before moving release to testing. Now I am just waiting till current testing becomes stable, so I can upgrade without trouble. And then upgrade to testing.

I have been with debian for long, and I like it, don't get me wrong. I think the stable/testing/unstable is a good idea, it is just not done properly. Stable should not have same bugs as testing/unstable once had. I will see how things develop, but whenever I find some time to play around, I will try other linux distributions. I mean howcome ubuntu has newest software and seems to me like it has same amount of bugs at any point of time.

[vbrummond]

Actually, I should run unstable, because packages in testing are still somewhat old.

Ok bro lol.

BUT, the excuse that stable is bug free, is a MYTH.

Where the heck did we claim that? The answer you would probably get from our members here is all software has bugs.

For instance right now, amarok plays each song twice in a row on random mode, I mean if this is not serious bug, then what is??

A bug in the upstream kernel causing data loss on it's most used filesystem? Now I know you are just trolling. Anyway to resolve that obviously upstream issue with Amarok the maintainer would either have to backport a (hopefully compatible?) commit (if it exists) from a newer version of Amarok, or upload a newer version of Amarok to backports and hope all of the libraries in Squeeze allow it to compile and run? Or upload the newest version in Sid and it will trickle down to the next stable where it is compatible.

Thus it seems to me, old versions in stable carry their old bugs solved long ago. From this point of view I don't see many advantages of stable.

And newer versions also introduce new bugs. And so on... This way at least you can 'know thy enemy'. And sometimes fixes are backported before the freeze for the next stable version. For example I am running Intel 2.19 drivers but I have the SNA acceleration available from 2.20.

Thus usual point "simply upgrade to testing" is not that simple and does not stand.

It could be more graphical and hand holdy but it is surely simple. Make sure to run simulations first so you know where you might run into problems.

The reason is that upgrade process is the last thing that is tested before moving release to testing. Now I am just waiting till current testing becomes stable, so I can upgrade without trouble. And then upgrade to testing.

This sounds like a reasonable decision. The upgrade process can have bugs now and then. It is part of the risks of using testing. It is in testing.

I mean howcome ubuntu has newest software and seems to me like it has same amount of bugs at any point of time.

Have you ever looked at Ubuntu's bug tracker? I say do what pleases you and be happy.

[stevepusser]

Or either add a repo with your desired backports, or get the source from that repo and build your own backports. Sometimes you have to drop a feature: for example, VLC 2.0.4 looks to build an ncurses interface with the libncursesw-dev headers on Squeeze, but they don't use pkgconfig, so we end up dropping that from the configuration and from the vlc-nox.install file (since it's seldom used).