This thread is a self-supporting argument for closing old threads.

But since that isnt LQ policy, and isnt likely to change, I look forward to acid_kewpie posting 'ARGGHH!!!! this is a *insert new number here* YEAR OLD THREAD, Why did you reply to it??' at some point in the future.

Although the fact that I got an answer to my question from a one-year-old answer to the six-year-old question suggests there are reasons to not close threads!

So it seems Qt is included in Ubuntu 11.10 onwards, though I happen to still run 10. A "sudo apt-get install libqt4-dev" did the trick for what I needed.

may i ask a qusetion? how can i post a post?

I'm so glad these terrible people replied to forever ago old threads - I would not have figured out my issue without them. Shame on them.

There is something still to be discussed from the original question, still causing problems today, and I think that is a good reason why it isn't a bad thing continuing the thread. The big problem is that:

sudo apt-get install qt

does not work... you have to know the (obscure) name of the package to install - something like libqt4-dev - when somebody says "You will need to install ... Qt 4.4.0 or higher". Sometimes there is a "meta package" or whatever, that allows the short name to be used when installing but often there isn't. Apache is another example. You can usually search for a package name but get a huge number of results that are usually irrelevant (and who is going to know there are two completely different things with the same TLA name?).

I think there should be some convention in package manager setups that means that a well-known name like "qt" or "squid" or "apache" (case-insensitive) should result in the installation of whatever is reasonable - the latest version of the package that is obviously meant. There should be a maintained, well-known list of packages that get referred to often so an average user (who is now likely to be less of a dyed-in-the-wool sysadmin/geek than a few years ago), as well as those looking after distros, should know it is safe to say something like "install nfs" and you can expect the explanation of how to actually do this doesn't have to change every few years or between distributions.

And it would also be nice if less specific requests (e.g. "install a web proxy" or "Fortran IV compiler :-)) could result in something sensible (e.g. a list of packages that could do the job, or a link to a website discussing options).

It isn't just that the installation process needs "idiot-proofing" - the name you must use (when installing, when finding man pages, when starting/stopping servers, and when configuring them - often not the same!) has gotten very, very complicated. And (to mis-quote the HHG) whenever we get to the stage of understanding what name to use in the latest distribution it changes to something even more bizarre and inexplicable. One way to work around the problem is to search the Internet for a good set of instructions that correspond to advice like "install a local dns server" - but the details of what to do will keep changing - while the most straight-forward approach is to improve the package managers and have a list of well-known packages so that people writing advice can be sure that, if a package is in the list, they don't have to go into great installation details themselves. The Internet (and print media) is littered with paragraph after paragraph of "If you have Fedora 8 or 9 do this... but if you have the latest slackware do that..." or even instructions that don't mention which distribution they will work with.

Mark

Hi,
The user should not expected to be able to guess an exact package name. Instead they should learn how to use "apt-cache search" to find out the package name.

Evo2.

I agree that the user should not need to guess the exact name, but the problem I was referring to when I mentioned searching is very significant: for many packages (especially those with short names) you can get f-a-r too many results, e.g.:

apt-cache search qt|wc
1153 9316 67506

None of the descriptions in the over 1000 results screams "this is what you want to install if you need to use qt!".

Similarly, a search for xv can result in many results, none of which is xv!

Then there are alternative names for some packages that may or may not work; apt-cache search httpd does NOT find the apache2 package you need to install (but finds lots of other things). Similarly the user has to know which alternative name (out of samba/smb/cifs or named/bind/dns etc) to search for in the first place - the "wrong" name will return lots of results too.

Basically, users have to already know quite a bit and/or do some very careful Internet searching (again, being careful to avoid out-dated or wrong-distro advice). Think from the perspective of a newbie user - how are they expected to proceed? Or a seasoned user that wants to maintain several systems with least effort. Rote learning of important tiny differences that change often between systems hurts efficiency, increases the chances of mistakes and gives Linux a bad reputation.

Notice that "apt-cache search" works differently to "yum search" when it comes to multiple words - adding alternative names to a yum search helps you find what you are after (a sort of "implied OR" but with the sensible step of listing first those results that match the most search terms) while apt-cache's search is reduced with more search terms. I have to say that the apt tools are not as well geared to sensible system administration as (say) yum, but neither is really good enough. But I don't suggest one person redesigns it all to suit themselves - t should be the result of an agreed-upon set of standards. If we can have "well known ports" and RFC's that are good foundations in their own respect then we should be able to come up with a foundation stone for linux package naming/management.

I don't think what I'm suggesting is hugely difficult. I think it involves:

1. a database of software titles (like "apache", "squid", "kermit")
2. a subset or index into that of pretty well-known packages that people should be able to expect to be able to say "install that" and each distro make sure their install program will translate the name into what is required
3. have apt-cache search work at least as well as yum's search when it comes to multi-word searches - preferrably going as far as accessing a network-based FAQ if really "dumb" searches are given (such as "search for anything that lets me share printers with a mac") and
4. it must always list packages that provide the very famous daemons: httpd, lpd, named etc.
5. It would also be nice, but not essential, to be able to be expanded to cope with the wide range of software linux can use after you install the appropriate pc/mac/Spectrum/Amiga/PDP11/microNOVA/etc emulator/virtualbox etc.
6. Also nice-but-not-absolutely-essential: allow a flexible software installation "channel" system so that, for example, an organisation might have one "install server" that restricts what packages can be installed (for security or support reasons, for example) and/or supplements the normal distro's packages, and possibly keeps track of licensed software, so when somebody on a linux (/windows/whatever?) system within the organisation wants to see what could be installed to meet certain needs they get a tailored list, and it should cope with having a linux package installed within cygwin running under Windows, or does whatever is needed to make an application installed on a shared server available to this workstation.

Mark

Try Synaptic Package Manager to install it

I've been installing HPLIP on my ubuntu machine and I found this thread useful.

Yeah, I guess the package name in ubuntu 14.04 is qt[version]-qmake. Thanks to rebroad in 2011
(the sdk fails to install)