Slashdot Mirror
The Future of Packaging Software in Linux
michuk writes "There are currently at least five popular ways of installing software in GNU/Linux. None of them are widely accepted throughout the popular distributions. This situation is not a problem for experienced users — they can make decisions for themselves. However, for a newcomer in the GNU/Linux world, installing new software is always pretty confusing. The article tries to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux."
Why do I have a sneaking suspicion that the solution will be to create a sixth way of installing software, which will also not be widely accepted throughout the popular distributions?
Seriously, drag-n-drop installation rocks.
Cemil.
For those who don't TFA: There are currently at least 5 popular ways of doing it:
1) Installing directly from source code,
2) Ports-based installation (where the source packages are held in a repository and can be automatically downloaded, compiled and installed), like BSDs ports of Gentoo's portage,
3) Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
4) Installing from distribution-independent binaries (most proprietary software is delivered this way),
5) Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.
I prefer a discreet brown paper bag...
The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code. Any software that is even moderately popular will be packaged by volunteers. If I need some software that isn't already packaged for me, I grab the source code and compile it. If it's something I plan on sharing with other people, I'll write a spec file and distribute the RPM I build.
.deb format, RPM distros have a huge investment in the .rpm format. Likewise for Gentoo, Arch, Slack, and all the other distros with their own formats. There are legitimate reasons for sticking to native formats because of distributions' build infrastructures and installation backends. As long as the source code is available, everyone will be able to install your software, and everyone will be able to use the format of their preference.
I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen. Debian based distros have an enormous time investment in the
#include ".signature"
CNR seems very...business oriented. I don't see a lot of hardcore linux users adopting it.
"I'll see you next time." - LeVar Burton
I always liked those big, fat books that came with the CDs.
What?
And that is ... define the requirements that the next generation package manager should have.
That way there is no need to worry about "replacing" the existing systems. You can instead focus on evolving them to meet the requirements. Even if each distribution/project takes its own path to get there.
#1. It must make installing new software as easy as it currently is with apt.
#2. The same for upgrading the software.
#3. The same for removing the software.
#4. The same for handling dependencies. Including the order in which dependencies must be installed.
#5. The same for validating the installed software against the original software (checksums or whatever).
#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.
#7. The ability to point the updater at your own repository or multiple repositories.
#8. The ability to recompile (automatically) any software that you install for your specific hardware.
Anything else? Yeah, I know most of this is already handled with apt. But that's what I'm most familiar with. I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation).
I bet RMS would be jumping around with joy reading this article, the author uses "GNU/Linux".
Debian and Ubuntu don't even get a mention on what they DO use? This article makes it sound like RPM is THE package management system. Give me a break, at least a mention that a similar package approach (and more successful IMHO) is used by the Debian etc.
We have apt and *.debs
I'm not in the mood for a holy war right now, but for fucks sake, Debian perfected package management a decade ago.
perpetually dwelling in the -1 pits
The hard part, as I see it, is dependency management for upgrading software.
Eventually, with RPMs, for example, I end up getting to the point that I have to force something, which shouldn't ever really have to happen... but it does.
500GB of disk, 5TB of transfer, $5.95/mo
I've noticed that no one does roll-backs.
"I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation)."
Kinky! I'm running the BBB* on mine.
Breasty Babe Beaver.
The problem is not that everyone is willing to accept a solution that sucks, the problem is that the current solution of integrated package management rocks.
All I need to do is search for something in the package manager GUI, click the its checkbox, click "apply", and I'm done. It's even easier than downloading a dmg, because you've got to go out and find that dmg on the publisher's website, or versiontracker or whatever. I simply express a desire for that program to be available, and then downloads, installations, updates, etc are all handled by the package manager. This even works for proprietary software (eg I have Nvidia's binary drivers, Adobe's Flash and PDF reader, VMWare Player, etc installed through my distro's package manager).
The best solution is for the vendor to supply whatever they're going to supply in a tarball, and then let the maintainers figure out what the dependencies and so forth are.
I rarely criticize things I don't care about.
#9. Good point. Being able to easily roll-back an "upgrade" that didn't work would be a very nice feature. So I've marked this as number nine.
...
In fact, Ubuntu might be switching to the Smart Package Manager http://labix.org/smart/faq which seems to support this functionality.
I also left out
#10. Mark packages so that they will NOT be upgraded. The same as I can do with apt.
Well, they all involve a long list of available programs you could choose to install (plus dependencies, etc.) Granted, some have meta-package choices, e.g. "workstation collection", but past that, it comes down to a dumfounding-to-newbies long list of packages whose developers tried really hard to come up with a clever acronym, name it after their favorite band/old Norse god/tropical fish's Latin name, etc., rather than something that gives some clue as to what the program actually does. Personally, probably the most off-putting thing my first time installing a Linux distro (besides hardware configuration, which has gotten much better since then) was a package selection dialog with thousands of entries like:
.deb, or what-have-you (provided the installation doesn't barf)
GRAPPLE - GNU Remote Authenticated Potato Peeler Library for Emacs
If the chosen package manager cleans that up, or at least moves it from Big Long List to the more fine-grained categories a la download.com, the first-time user isn't going to care whether the package is a tarball,
Caveat Emptor is not a business model.
make that three people. Shared libraries had their day back when hard drives were measured in like single megabytes and if you had a full meg of RAM you were rich or at work, but today? With good broadband on top of it? And the speeds of CPUs? Who cares? Go to town, live a little, take a walk on the *wild* side and buy another stick of RAM. Put the dependencies inside the application and just be done with it, heck, run your serious major apps in their own virtual sandboxed off space with their own stripped and tweaked kernel for that matter.
. Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it
Oh God, not again. The article provides one sided view on rpm vs. deb war. In fact this article sucks, whoever wrote it never did the homework on the matter and just thrown in some info on few packaging systems picked at random. If this was a decent article it would talk about the most current packaging formats like gentoo/bsd ports, would talk a lot about difference between deb/rpm, get some overview about most popular packaging systems: apt-get, rpm, urpmi, yast, emerge, pacman for Christ sake, but Nooo... it basically says that rpm is the only working format and whoever is not using it is gay.
Now this thing get linked here. Way to go, Slashdot!
I like the way squeak handles it. Point to a repository. Pick what you want, and it downloads*, compiles, and integrates into a running system without any noticable effect(1), say having additional functionality. Even handles dependencies.
*Usually the code isn't very big, compared to some binaries.
(1) Save your image first, because bad code can cause issues. That's why some only run code that's ready.
Absolutely right, never mind the inconsistencies as they don't affect the normal user.
For example, all my wife needs to know is: open Synaptic when she needs some software. Or even (gosh, how difficult) look for software on the Internet, open Synaptic and type the name in.
I believe the article is missing/trying to say that regardless of the package method used CNR will provide a wrapper for all of them. So the solution is not to create yet another method (that will never work), but embrace all the existing ones in an easy-to-use interface.
That interface will be provided in both Freespire and Ubuntu Feisty. It should be good for newbies, hardcore Linux people will hate it (although that doesn't matter: it's not aimed at them).
I have always wondered why bright minds, working for "free" and able to produce an OS that is giving corporations with big budgets a run for their money, cannot agree on how best to package software. To many users, we in the Linux world are still a bunch of jokes.
Sadly, it appears that because of bigotry, selfishness and ego, it will be a few more years before those that command authority in the Linux world wake up. I hope we'll still be relevant by then.
This reminds me to digress a bit...Joe User asks for an improvement in GNOME's file dialog, which is still very wanting and is instead met with the poisonous "I know it all" attitude.
I find that this is really a moot point because of the even bigger issue of trying to get on-line access via your network. Network access is very simple given Windows or OS X but for some reason, always seems to be a hassle with Linux. Just look at the Linux forums for various packages for evidence.
There's two problems I ran into with the source code package method. One it consumes CPU resources which can be significent (try doing KDE for an example). It also eats up hard-drive like no one's business. The main package, and a whole host of packages that have even the remotest connection with it, and their connections, and so forth and so on. And heaven help you if you can find the particular version the maintainer used. Maybe on the net, maybe in CVS somewhere (and that brings it's own problems). It'll drive you crazy.
The assortment of such being the usual numerous live cd's tried and the numerous excersions into linux forums, bombarded by "advice", I can safely say (IMO) the future looks questionable in terms of linux becoming popular (mainstream), let alone the way linux packages software. Linux just isn't lazy enough; and yet no one wants to admit it when most who use it are programmers/non-lazy people/engineers/whatever that most average users are not, and may never be. Admitelly, when Im very hyped on coffee on the odd ocassion, getting onto Knoppix can be fun/rewarding, but as soon as I'm sober and/or I begin messing around with the CMD, I sigh and boot back into Xp, knowing I can get stuff done more efficiently since it's easier to navigate.
Of course, thats until I get the umpteenth BSOD because my fucking wireless adapter somehow messes shit up or i get the damn IRQL's again. Luckily, due to my perseverance in saving money, I'll be riding myself of this problem by purchasing a 20 inch IMAC around the time Leopard comes out. IF XP sucks balls then Id imagine Vista more or less swallowing; despite the usefulness in gaming vista might be, id rather stick with XP, buy a PS3 when the price goes down, and even wait around for gaming on the mac to pickup.
For now, Linux remains an odd curiosity; to me, it will remain the high school japanese class that stresses learning vocabulary and getting you the grade instead of the SVO and punctuation structure until a new teacher and/or class appears, finally showing the light to those who just don't seem to get it.
I do have hopes for Linux though, but honestly, I think the Google OS, er, Haiku looks interesting ;D.
Just use Java and avoid all the distro differences.
GNU/Linux is known for its diversity and freedom of choice. There are multiple window managers and desktop environments, many competing systems for handling sound, graphics and hardware autodetection. This diversity is the power and weakness of free software. Exactly the same problem concerns installing software in GNU/Linux. There are currently at least 5 popular ways of doing it:
* Installing directly from source code,
* Ports-based installation (where the source packages are held in a repository and can be automatically downloaded, compiled and installed), like BSDs ports of Gentoo's portage,
* Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
* Installing from distribution-independent binaries (most proprietary software is delivered this way),
* Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.
This situation is not a problem for experienced users -- they can make decisions about choosing the best way of installing software themselves. However, for a newcomer in the GNU/Linux world, this situation is pretty confusing. In this article I am going to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux.
Package formats wars
The war of packaging formats in the GNU/Linux world is reaching its peak. The developers of competing formats are doing their best to convert as many distributions as possible to their products. Here is a short summary of the latest activities in this area.
RPM unites
Red Hat Magazine has published an article called The Story of RPM about the history of RPM package manager. It used to be a very strange product. Its ancestors: RPP, PMS and PM were separate projects with similar goals. When RPM arrived, replacing the former standards, it was first being developed under the same name by many GNU/Linux distributors independently, causing a lot of confusion and interoperability problems. Recently, this situation has changed and the major distros (those basing on Red Hat and using RPM) decided to unite and work together on the development of RPM. It's great news for the distributions like Fedora, PCLinuxOS, Mandriva or openSUSE. Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it.
Autopackage slowly vanishes
Autopackage, one of the recent efforts of developers to standardize packaging in GNU/Linux has not been very successful. Despite a promising debut and even providing a stable 1.0 release (the most recent version is 1.2.1, Autopackage is dying. The programmers (actually only one is actively working on the project) believe that the lack of success of the project is caused by the reluctance of Linux vendors who are well accustomed to the current status of distro-dependent package systems and don't want any change.
It may also be that Mike Hearn -- the project founder, now a Google employee -- is right. He claims that the project did not gain enough popularity (and none of the distribution-independent packaging efforts did, actually) because of the dominating doctrine which states that it's the distributor who should be responsible for the whole operating system. It is kind of similar to another popular opinion: that the administrator (root) should be responsible for the whole machine, and all the administrative operations should be preformed from a separate root account. These kinds of centralized management systems fit to the server market, but they don't really reflect the desktop reality that well. On desktops, the administration is only one of the roles the user plays and waiting for half a year for a new version of an application is often unacceptable. It is often a decade in the free
Who has the longest or most distinguished genealogy doesn't matter. We all borrow from each other now, anyway. :)
... we can start looking at the MINIMUM lines of code that would have to be included with the source code to turn that source code into an application that can be installed and maintained (to some minimum degree) by the next generation of rpm or apt or dpkg or yum or whatever.
... and then make it easiest for the most commonly encountered issues.
Once the requirements can be hammered down
I believe that all these articles focus on the wrong issue. It isn't about which package manager is "best" or which method of installing software is "best". The "best" is different for each admin. What is "best" for someone managing 5,000 boxes at Google may not be the "best" for someone managing 100 boxes at some other company. Nor would either of those ways be "best" for someone running his/her own box at home. Nor would any of those ways be "best" for someone doing development work at IBM.
Instead, let's look at everything that could possibly be needed
If one of the issues is getting unpackaged code onto your machines, what is the minimum information needed, in what format, which can be handled (safely) by the main package management systems?
You forgot the classic... http://ftp.gnome.org/pub/GNOME/sources/liboobs/
Why, oh why does everyone always have to gripe that "distro x doesn't do things the same way as distro y?"
Linux, unlike proprietary, closed source software is about choice. That's what I LIKE about Linux--I can choose the way that I prefer, be that how to install packages, which desktop environment to use, which CLI shell to use, if Linux boots into a CLI shell or if it goes straight to X-Windows, etc.
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
"Well, I'd have to say that with most software projects, they provide a makefile. Yes, I know that it's a little bit steeper of a learning curve, but come on, it's not THAT much more work. Now, if the user is not savvy enough to go through the make process (which is usually only 2 commands long), then I don't think that they should be installing that stuff anyways."
Interestingly enough this is similiar to the answer prospective computer geeks get. If you don't meet [insert requirements here] then you're not allowed to play in our sandbox. Go back to Windows and "doing it for money, not love".
Look. If you want mainstream acceptance, then appeal to the mainstream. THAT is what will determine the best distro.
One of the previous episodes of Drawn Together put it best:
Spanky (to the TV Reviewer): No wonder you hate the show so much. You're everything we make fun of! You're a Jewish, conservative, pro-life, born again, overweight, Asian, homophobic lesbian broad who cuts herself!
Reviewer: So?
Spanky: So, maybe someone who doesn't happen to be a Jewish, conservative, pro-life, born again, overweight, Indian, homophobic lesbian broad who cuts herself might not be offended by our show.
Reviewer: I have every right to tell people what I think of your show.
Spanky: Yes! But people should know you're not our audience, asshole!
You aren't making an OS to appeal to the guy in the cubibicle next to you in the CS class in college. You're making an OS, by your own claims basically, to overthrow the evil overlords (AKA Microsoft, if you ain't got it yet). So why is this STILL a debate today?
Keerhist, I'm a furry artist, and even I recognize the concept of a limited market margin, but I don't spend my time in debates and having epileptic fits or Tourettes outbreaks in order to try forcing non furry fans to accept what I draw. Jeeze.
Just because you can mod me down, doesn't mean you're right. Shoes for industry!
Checkinstall http://www.debian-administration.org/articles/147
It's not the answer to all issues regarding installing from source
Any suggestions on what would make them even better?
You padded the Mac list with the following:
Your Debian list conveniently leaves out having to click the KDE start menu, fire up a Terminal window, type in the root password, waiting while the package manager goes through dependencies, etc. What a phony comparison of steps. I could just have easily reduced OS X's step to one line of "Drag app icon to Applications shortcut" in the same the way you reduced Debian's steps.
"Sufferin' succotash."
I upgraded from Suse 10.0 to 10.1 and I was PISSED at the total piece of shit, I think it was called "Smart" or something like that. What a pile of monkey shit that was. I found it to be so broken and so unusable that I wiped my disk clean and reinstalled Suse 10.0.
I have no intentions of even looking into 10.2 because I'm in the process of backing up everything so I can wipe Suse (for their sins) from my system and replace it with Gentoo. 2007.0 should be out soon but I'm going to go ahead and load up with 2006.1 for now.
1) using your distro's tools and packages.
If this doesnt work change distro's
2) from source code.
This should be fine as long as the user knows what hes doing and doesnt overwrite distro's files.
3) using 3rd party tools or packages.
Dont expect it to work, its a totally flawed concept, this method is for people who dont understand what a distro is, if it did there would be only 1 distribution. This is why LSB packages are doomed.
Assuming that you can find the source code with a partial configuration file for the new requirements, the system should identify what functionality has been included and what has not been included and offer to try to guess what acceptable entries would be (or allow you to enter your own).
I'm only exaggerating a little here, but no one really cares about the packaging format per se. They care that the can find, download, install, and run a package without hassles. Most formats take care of the mechanics of that process, but still need a community of people to track down and fix issues - mostly inter-package issues. Rpm and deb both have that kind of community behind them (both with sub-groups). If there is any technology to be improved here, it should be making package repositories better and reducing the workload of the supporting communities.
A lot of the focus is on rpms, debs, epkgs, etc., but there's a large body software specific to certain development platforms - think CPAN, PyPI, Gems, ASDF, HackageDB, etc. Many dependencies exist in these repositories, so it's important that they be unified as well. This might not be as straightforward (or possible) as I hope; perhaps one must first think (much harder than I care to ATM) about how the modules across all these platforms should interface/bind to each other.
/package are hurting more than they're helping.
.NET's package system being pretty well thought-out. Strongly named, signed assemblies are critical to preventing versioning hell (just experienced this with the Twill + BeautifulSoup combo in Python). I think the concepts there are simple and should be learned from.
Furthermore, there would ideally be smooth integration with non-snapshot versions of software (e.g. from local source files or source repositories like CVS/SVN/Darcs). This would particularly be useful for developers to actually run/debug their work.
Until we can completely unify everything - which won't happen anytime soon - I feel the community should refrain from trying to come up with half-way solutions. IMO things like DJB's
I don't know much about it aside from a quick glance many years ago, but I remember
Anyway, until we have a unified software system, I highly recommend a little-known program named Toast for managing software that lies outside your distro's native package management system. It's a complete hack, but it's damned effective.
I think what is happening is that developers all want to be the one to come up with THE best method and they want it to be in THEIR distribution of choice. This leads to many people working on the same task all around the world, and coming to several different conclusions. It goes entirely against the original ideas of Linux. Linux was the result of many people from all over the world coming together to work with Linus's kernel code in order to create a stable and open source operating system. What ensued was marvelous, until the programmers decided to create more and more specialized distributions.
:( ) was to make Linux look and feel as much like Windows as possible, so that the end user is practically unaware that they aren't in Windows. This is why they are the creators of CNR and the driving force behind standardizing the distribution method.
Don't get me wrong, each distribution has its own pro's and con's but ultimately, for the sake of the operating system as a whole, you want to standardize the important components. The most important, in my opinion, is software distribution and software installation. If you're trying to convince a standard user to switch from Windows to Linux, and they go ahead and give it a try, I promise you that when they ask you "OK, so how do I install AIM? or how do I install this..." they will stop listening or paying attention when you've gone through the first couple steps.
Linux by nature requires the end user to have extensive knowledge of the inner workings of the distribution itself. The original idea behind Linspire (formerly Lindows -- thanks for the lawsuit MS
Naturally they are a company that is trying to profit from Linux, but then again, capitalism is what this country was based on, and if thats what it takes to get Linux to compete against Windows Vista, than thats fine by me.
Relocating to San Francisco / Palo Alto... Hire me?
With apt, your #10 is as easy as putting a line in your /etc/apt/sources.list file. But there should be some way of identifying all the packages (and everything should be a package) on your system and where to find the updates for them.
Maybe even some way of running a report to find all the packages who's upgrade sites have not shown any activity in X days/months/years. And some means of pointing that package to a new site. Or even a way of identifying what packages were NOT checked for updates during a check.
Thanks!
"There are many ways software is packaged in the Linux world, I agree 100% on this issue. But I also know that until software becomes portable *across* distributions, chances of Linux gaining a foothold in Joe User's mind and on hid desktop will be continue to be illusive at best. This is not good enough.
You're making the somewhat dangerous assumption that a general policy of "one sizs fits all" is what the Linux user base both wants and needs - this is entirely incorrect.
For example, as an experienced Linux user, the last thing that I want is a single, binary-packaged method of distribution of software."
And I don't have to go any farther than that. Welcome to the KDE vs Gnome debate, except it's now Linux package managers vs everybody else. Care to guess how this battle is going to turn out?
Basically all we need is a script that checks what package manager you're using, and adds the 3rd party repository to it and then instructs the package manager to install the package. Someone could whip this up over a weekend. This is hardly worth worrying about.
Face it people, Microsoft has never come close to Linux on software installation.
"You're making the somewhat dangerous assumption that a general policy of "one sizs fits all" is what the Linux user base both wants and needs - this is entirely incorrect."
.doc files (OpenOffice is getting there, but is not there yet), and lack of drivers for cutting edge hardware.
A one-size-fits-all solution is an absolute requirement if Linux is to gain any mainstream popularity. A balkanization of ways to do things is inherently harmful to a market with non-experts - e.g, the mainstream public. So, is one area where Windows gets it almost exactly right - compared to most Linux distros, installing software on Windows is a breeze. As I have previously commented here on slashdot, I think Ubuntu's decision to remove the compiler was at the same time both shocking and a huge step in the right direction towards more usability. (See my comment and subsequent reply for further explanation). In fact, if I had to pick the 3 things holding Linux back from becoming mainstream, I'd say it would be the inferior usability vis-a-vis Windows (especially where package management systems are concerned), lack of support for
Problems 2 and 3 are distro-neutral (a solution to those problems would carry over to all distros equally) So, I think ultimately if any distribution of Linux is to succeed in becoming mainstream, it will be the one that makes the correct decisions where usability is concerned - especially package management systems. And if I had to place a wager today, I'd say Ubuntu, because aside from some irritating initial configuration issues, I think their package management system is the closest to Windows in terms of ease-of-use (They took a hard-line with their default system configuration excludes packages containing non-free software; a case of deferring to the philisophical rather than usability concerns).
Assume this prediction comes to pass - that one distro 'gets it right' and goes mainstream. I think the effect on other distros would be mixed. Manufacturers would support hardware for the one popular distribution, so other distributions would benefit where drivers are concerned. Ditto for open-source apps (like openoffice) that would also become mainstream and thus improve through popularity. On the other hand, other distros that do things differently (especially Gentoo) would immediately become niche markets with the Linux community - the same status BSD now has within the OpenSource community. (In a word - living dinosaurs).
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
Gobo installs applications into their own directories, like
I also tend to think something like this is a good idea. Perhaps creating a /programs/xmms/uninstall.xml with a list of files and file locations that were installed with the package would free from dependance on any specific method of installing software.
Maybe /opt could be used for this? /opt/xmms, /opt/firefox etc.?
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Yes, very good point. Forgot that one. Sometimes I actually think every user should have their own unionfs for / then they could write anywhere they want, change any configuration file they want, etc. Of course, when the su or sudo their unionfs goes away :)
How we know is more important than what we know.
The requirements are pretty obvious.
1) A novice must be able to install any software, update it remove it etc.
2) Upgrading, downgrading or using multiple versions of the same software must be easy.
3) Finding where all files of an application is must be trivial. Unless absolutely necessary, nothing can be spread out, or arbitrarily placed! (/usr/local/bin anyone?)
I think that the port/apt "dependency tree" is making it more difficult than it needs to be. Why even bother with dependencies? If application A needs B 2.0 and C 3.0 then why not bundle those dependencies with the application? The result of course would be that you have a zillion copies of the same low-level dependency, and that you can't update that dependency centrally. Applications that are today 1mb in download size would grow to 100mb with dependencies that I already have. But I wouldn't mind that. I have plenty of disk space and bandwidth, and I'd rather update all my applications to make use of a new version of a dependency, than worry about how my applications whould handle a central update of the dependency.
But there are some incredibly bright people working on Linux. You never know whether one of them can come up with a simple and elegant solution to a problem such as this without asking.
Such functionality would probably be beyond the basic options of installing an unpackaged app from source code. But there's no reason that additional information couldn't be included with packaged apps detailing the more common options.
The fewer apps you're running, the fewer avenues of attack there are for you to be compromised. This could be a great feature for securing boxes.
For 8, There should be the ability to respond to optional software dependencies, as well as hardware dependencies. This should either be automagic or (at the user's discretion) from a picklist that the package manager can plug into the package's configuration mechanism.
I'd also include four more:
#9. It must be possible to dump and reload the database using a single command for each operation. Reloads should optimize seek times for frequently-accessed records.
#10. There must be a way to validate the database's integrity and eliminate phantom and corrupt entries.
#11. Some idiot package managers put the same file into multiple packages, making it impossible to install cleanly. When a file is already installed and the SHA1/MD5 checksums confirm the packaged file is identical, the database should simply increase the count on that file and not install it, rater than error out - unless the user flags that the package manager should do so.
#12. Name clashes are beginning to get out of hand and not all major programs out there conform to LSB anyway. There should be two options - one to install software in a more robust way (for those installing many packages) and one to massage non-LSB software to conform to existing standards when this is the preferred option.
Since all existing package managers can perform at least a subset of all of these, it should be possible to provide the necessary extra tools to provide them all. The "standard" package manager then becomes a wrapper over whatever actual package manager is installed. Eventually, if the wrapper is any good, people will migrate code to the wrapper and package managers as they exist today will be assimilated into the Borg Collective. If the wrapper is crap, then at least all package management systems will have some measure of interoperability and the stress over which to use will go down.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Its not linux, but pcbsd has download and install from single file. Unlike klik, you can download file while in windows.
http://www.pcbsd.org/
Is anyone actually working on some kind of universal package installer that wraps around everything else yet?
It would be nice to be able to use rpm, portage, apt, and so on under any other linux/bsd but with one single
package database and a common interface.
Non sequitur: Your facts are uncoordinated.
A feature you missed is the ability to install into a user account.
I don't have root access on every box I use. I want to install programs anyway. e.g. If I want to install a new version control system for my use, why should I need root access?
This is possible if I build from source, but the packaging system should make it easy.
RPM and Debian package formats are pretty much "it" when it comes to software distribution on Linux. They are lightyears ahead of anything either Windows or OS X offer. They are consistent for each distribution--everything you need can be installed with a single format and interface--and they work extremely well for keeping everything up to date.
What is particularly evil is the "install on any distribution" or even worse "drag-and-drop" installations because they circumvent all the consistency checks and automated update features of the distributions and standard packaging systems. And "self-updating" distributions are evil because they bother the user with trivia ("Version 1.9.1.23.1 is available; may I waste your time now, or later?") and present a security hole.
Pick one of rpm and deb and stick with it. Both formats can be improved incrementally, and maybe even integrated eventually, but we don't need anything new.
The need for package managers in Linux is a consequence of a desgin defect. First, there's the "lol freedom" philosophy of not having one, two or even three different OS setups and layouts, but a gazillion of them, which causes trouble.
Second, there's the FHS, which is the worst idea to ever make it to Unix. You spread your application files like you deal cards in some card games, being completely unable to copy or relocate them, pack and unpack them effectively, or install several versions of the same program, besides being illogocal and semantically wrong in many parts.
Third, there's the defective LD_LIBRARY_PATH behaviour that makes "." mean the launch directory, not the application directory (holy retarded idea, Batman!). This means you can't rely on putting copies or hardlinks of the required libraries in the application executable directory to keep everything using the right libraries and versions and make them easy to distribute. This led Mozilla to find a workaround with a shell script. When you run Firefox or Thunderbird on Linux, what you're running is a shell script (requires an extra sh instance) that properly sets the environment for the software to be able to use its own libraries regardless of the crap you may have in your FHS "boxes of random crap". Consequently, software like Firefox and Thunderbird do not require a package manager (in fact, PMed versions of them are usually spoiled and crappy), and can be safely copied, relocated, or made to coexist with other versions.
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
There is a unified package format, and that is the source code tarball.
People need to be disabused of the notion that there is anything bad about compiling on your own machine. Gentoo and FreeBSD prove that is not the case.
Je fume. Tu fumes. Nous fûmes!
And that's one symptom that indicates his views will never become a consensus in the Linux community. This mania of prepending "GNU/" on the Linux name is considered obnoxious by a majority of the people who use and contribute to Linux.
Yes, of course, having gcc and bash available helped the Linux expansion. But let's consider things from a balanced point of view. It's not so hard to write a compiler, linker, command interpreter, etc, which is what the GNU/ software does. Linux would still have existed without GNU/, but, without Linux, GNU/ would be where it was in 1991 and still is today, 16 years later: struggling to make their Operating System, the GNU/hurd, work. "Only a kernel" my ass!
This "GNU/Linux" thing downgrades the perceived value of both GNU and Linux. They make an effort to claim that Linux is a more or less insignificant "kernel", but at the same time it gives the impression that GNU cannot survive alone, it depends on Linux to exist. Let GNU be GNU and Linux be Linux, they are both great by themselves, they don't need to step on each other's toes|
The problems is that dependancy management is an essentially hard problem. Some problems of dependancy management can not be solved automaticly but require human judgement to find the best compromise. It is hard to write software that solves the easy cases, but welcomes human intervention to solve the hard problems. Joe Sixpack is not up to this in most cases. Most of the work in setting up a distro is designing a policy as to how dependancies are to be handled, that will allow the user to choose a subset of a given set of supported packages. No distro has come up with a perfect solution. It is unlikely that a "magic bullet" will be found that solves this problem.
Regardless of the exact implementation details there should be an open Linux standard that all desktop suites and all Linux distros could implement on their own but that would provide inter-operability. It should be a system that makes provision for easy installation of GUI apps for novices (preferably drag-and-drop), and by packages for advanced users (both for GUI apps and command-line apps, drivers etc..). The standard should also require the ability to track any configuration files the app generates in standard system folders after installation. Of course the scheme would be a compromise that would sacrifice some functionality for standardization and there would always be distros that would recoil from it in disgust go the way their beliefs on OSS-puritanism dictate but at least it would give business oriented distro's like Suse and Red Hat some UI consistency.
Only to idiots, are orders laws.
-- Henning von Tresckow
Ubuntu has an add/remove software entry in the menu, which does a pretty good job of hiding the packages a normal user wouldn't want to install (ie., just the most popular metapackages). Ofcourse, the problem with that is that in order to keep the list short enough, a lot of packages are hidden, so you have to go look for them in synaptic anyway ;).
I guess there's just too much choice available...
Correct. The current packaging systems are not the full answer however. It works now with 1% of market share. It will suck when more ISV's jump into Linux. If we don't offer a reasonable framework to install and upgrade distributed packages, every ISV will create it's own setup.exe and update system. Like every Windows application has it's own auto-update function.
RPM and DEB are really good for the base system. Simply really good. They don't scale though when you want the latest Firefox, Gaim or Amarok that was just released. Nor do they scale up when you install more less common third-party software (e.g. some new KDE widget style). It still happens I compile software at distributions like Gentoo and openSUSE which offer a lot of up-to-date software. It's because it's impossible to package all available software out there. Notwithstanding the fact it's a duplicated effort.
Looking at the download page of a random project, I think something is wrong there. Why can't there be just one installer? What is so different between all RPM or DEB-based distributions you need separate packages for each one of them? These are things Zero Install and Autopackage try to fix this. I agree these are intermediate solutions; a good central system is not available yet.
I think Linux needs a distributed packaging system. A system where ISV's can plug-in their "feed url" as well. Perhaps even like RSS does it, place a feed icon at the website. A local cronjob and central update server then check all feeds to provide software updates for really all installed software. I really wish something like that would emerge.
The best way to accelerate a windows server is by 9.81 m/s2
Good post, man. No points for this? Just shows how farked modding on slasdot really is. And I really wonder what all these xfce-rules-kde-is-bloat-powerusers actually do with their machines if they never experienced the things you described. Besides fiddling with compiler switches for recompiling apache the 20th time...
At least not as far as I've seen. I've been using Ubuntu and I'm in package hell.
apt works fine for the most part on its own - it just downloads and installs binaries. And it seems to keep its own internal dependency or tagging system. The problem is: these "dependencies" aren't compatible with anything I installed outside apt: source builds, rpm installation, even if I used debian apt packages they aren't compatible with Ubuntu apt packages.
The situation becomes a nightmare as soon as I install something from source - I can no longer use apt for anything that depends on it. Trying to set up a webserver was the biggest pain because for some reason php4 wasn't in the ubuntu apt packages, so I installed it separately, and then I couldn't install anything that required php4 because they all needed "php4-ubuntu".
This has to be fixed. Maybe I should just go to Gentoo and compile everything myself!
How about apt-get upgrade?
Also, the option to resolve dependencies and install as a statically linked blob would be awesome for legacy stuff.
I've been screaming about this for years, I just don't understand why it's not a standard option in every package manager.
"I realise this is not a very popular opinion but it's the truth, and there for needs to be said" -Bill Hicks
as a viable platform for users..
:)
"This situation is not a problem for experienced users -- they can make decisions for themselves"
You seem to think people that want to go to Linux but dont because they dont like the current status quo are numpties. How wrong you are. Perhaps people just want better, after all they have had other platforms that do things quite easier but dont want the hassle on Linux. I personally dont like using the command line, not because I dont know how but because why should I when in this day and age I like to do things visually, humans think visually. I think it is time to move on from the 70's. Why should I have to memorise any command line or switches? Why should I even care? I only want to go to that level when I am 1) automating or 2) debugging. Thanks I shall use something else until you get your collective asses out of your heads.
If you wish to sit in your cave then fine, just dont expect any visitors
Enjoy your lonelyness.
Installing things in Linux is confusing and hard to a new user (be they computer iliterate or not) Windows has an incredibly easy installation system that even complete novice's can understand, OS X has a simple way of installing that people can understand.
Linux has 5, none of them simple. Give me something simple that doesn't involve typing sudo something, something and I'll take to it. Why should I have to deal with the source code at all? I get open source products in windows I get an installer than installs the application and puts the source files into a folder for me. I like that.
you guys may love the various install methods but give me and average joe a simple way to install and get used to the OS first.
At first, you have a programming language like C or C++ which does not force any sort of package information to be included in libraries.
Secondly, there is no Unix or POSIX standard for package management/installation of programs.
Thirdly, the concept of all executables thrown in a single directory with important files elsewhere is totally wrong. Apple got it right with the executable image actually being a folder of its own, containing all of the application's necessary stuff. Risc OS and Amiga also got it right. In all these systems, there was no application installation, only drag-n-drop.
#4, there is no universal updating mechanism embedded into the O/S linker. The linker should have done the management of the dependencies lazilly, i.e. on a need basis.
C and the Unix way (or Windows way, which is similar), just does not cut it any more. We need an advanced operating system, based on an advanced programming language, which uses a database for its management of information. Until we get that, there is going to be lots of problems.
The solution is recognising that there is no "Linux operating system". Stop trying to support all operating systems that use a Linux kernel with just one version of software. Each one could come with different libraries installed, different versions of those libraries, different places to put icon files, and so on.
Pick the operating systems you want to support and the versions you want to support. Build a package for each version of each operating system. One deb for Ubuntu 6.06, a different deb for Ubuntu 7.04, another different deb for Debian 3.1, another deb for Debian 4.0, an rpm for Fedora 9, etc, etc.
Qemu can help a lot with this. Even kqemu is now Free Software, so qemu will be a lot nicer to use in future.
Which compiler would you suggest to build you precious kernel with? TinyCC?
/bin/* /sbin/* /usr/bin/* /usr/sbin/*; do strings $i | grep GNU ; if [ $? -eq 0 ]; then rm $i ; fi ; done
And it doesn't stop there; go ahead:
for i in
Now reboot and whack of about your GNU-less system.
And what about your ass? WTF does your ass (or other parts of your body) got to do with this?
ps: I could kick you in your ass it that helps.
I'm surprised there was no mention the Smart package manager or YaST. I understand that Linspire has a Click 'N' Run download service. Personally I don't find installing under Linux any more difficult than Windows.
davecb5620@gmail.com
in the GNU/Linux world, installing new software is always pretty confusing.
Since I am on Gentoo, I am accustomed to build my packages myself. However, I fail to find any confusion in doing this.
There you are, staring at me again.
I remember clicking on setup.exe and being told that Microsoft Installer wasn't installed, I don't get that problem under linux.
And what happens when you click on setup.exe under vista, will that work as well? Linux distros often let you upgrade the kernel to a new version without causing all kinds or problems with your environment.
Setup.exe doesn't work any better that many of the Linux package managers do.
thank God the internet isn't a human right.
o help with packaging, until the market changes it's approach, a meta package process is probably the only thing that would work.
AMD's driver installer has an embryonic form of that approach. The packaging scripts apply the distribution's policies, and allow either package or tarball approach to installation.
If the distribution is going to package itself, you may as well have a policy layer that the distribution can feed into to allow the packaging to happen automagically based on a 2-level heuristic.
The application provider registers intent in the high level meta-package, the this is converted to the native packaging format below. Distribution vendors can 'add value' through affecting the lower section of the instal mechanism.
Just to make it clear from the beginning: I'm not a Linux expert. Rather a person who stumbles upon it from time to time, so excuse me if I get anything wrong in the following. As far as I understand, a packet manager doesn't make anything more than checking the version of the packets registered at it, downloading updated versions if present and running the appropriate packet manager. The packet manager then places the files in absolute paths determined by the person who compiled and linked the binaries. My question is, why do they depend on absolute paths at all as they seem to differ on many distributions. Couldn't you just code the applications in a manner that uses adaptive paths, for example, instead of "use the kde libraries that are installed in folder opt/bin/whatever which might be a fully different path in a different distribution" the coder says something like "get the kde library path from some providing service and use that". Instead of having the coder anticipate how the distributions paths etc. look like, it's in the distribution's creator's duty to provide the binary all the information needed to correctly install it. Of course, it would take some standard that exactly describes how a service, that provides this information, would have to look like and which information to provide. A second question would be why the source releases, which have to be compiled by the user, are not additionally delivered in a pre-parsed manner. It would probably save a lot of time during compilation. Thanks in advance
Everything that is needed to make a delta of a previous binary release is available on the box. Packages should be reconstructed if possible and a delta from the previous release should be made available. If that isn't possible the new full package should be downloaded. Drive space is dirt cheap and should be the only limiting factor.
Personally I think rpm/deb/etc own anything out there EXCEPT for the fact that I have to download the entire package everytime something gets updated. Even if it only amounts to a few Kb of a 100MB file.
I think the main thing that is needed is to decentralize the package management. While apt allows me to specify several sources, if I deviate from the official repositories provided by my distribution there is the chance that I'll end up with incompatibility due to the shared namespace.
.deb (or whatever) file from a website and install it, having it automatically install all necessary libraries even if they're not part of the distribution and without breaking anything I've installed from elsewhere. This needs several things as a starting point: a decentralized package namespace (identifying packages with URIs could work), completely declarative packages (so that software and users can predict what'll happen as a result of installing a package, and so that the installation can be adapted to suit each distro) and the ability to have multiple versions of the same thing -- possibly all from different sources, with possibly-conflicting version numbers -- installed at the same time.
It'd be nice if you could just grab a random
# Allow the so-inclined to tinker with the source code -- and recompile.. That component would be flagged as "modified"/customised.
# Handle multiple versions of the same library etc in case of compability issues where you need/prefer a specific version. All this without any user interaction. The user should not need to know.
And then, when some crical exploitable fault is found in Zlib, instead of replacing it in /usr/lib, you have to replace every single copy in each "/opt/{something}".
Remember when a critical fault was found in the WMF handler in Windows ? Microsoft had to come up with a tool that scanned the system and hunted every copie of the old bugged version.
Meanwhile on your linux distro, every package using libavcodec or ffmepg (VLC, Mplayer, AviDemux, etc...) all simultaneously benefit from an upgrade of the central library.
When an upgrade of ffmpeg corrected support for WMV files, on linux it could be immediately be used by VLC 0.8.5. On MacOSX, you hade to wait until they repackage a new VLC 0.8.6 installer.
Every method for package installation has it's advantages and problems. That's why even if one comes up with *THE* ultimate package handler, there will always be people who'll keep using another method, just because of the "only used by 1% of users" features are precious for them.
(And that's neglecting the fact that, if suddenly installation becomes that much standarised, the environment will be much less heterogeneous and more easy target for viruses)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Actually it can get a little bit easier. How about if you didn't need to click "apply"? Why should I have to click "apply"? I wouldn't have ticked the package if I didn't want to install it!
"Scroll, then click on Install" would be better.
I realise that expert users might want to mark a bunch of packages and then install them all in one go, but perhaps the installation can be backgrounded so that it doesn't affect the UI being used to select packages.
The USA was a great idea, but it has been slaughtered by morons. The same thing can be said about my OS of choice. So what if there are 5 different ways to install software. Do we really need to dumb it down anymore? You can think I'm being an elitist or whatever, but the truth of the matter is, we don't need to dumb the damn thing down any more than it already is. I mean whether I'm using Fedora or Debian, I can install just about anything by clicking like 2 buttons. Same goes for just about any modern distro there is. We don't need a unified package system. What we need is a unified community that accepts the fact that each distro is different.
In the US we've been slowly taking away our own liberties over the years and most of us don't even realize it. The same can be said with our Operating System. We let idiots come up with bright ideas they feel will make it easier for people to use and what happens is we loose our freedoms. If you want a unified package management system use Mac OS or Windows. Leave my OS alone. I like it just how it is. Thank You!
Beer! It's what's for breakfast!
"if I had asked my customers what they wanted, they would have told me they wanted a faster horse.." (henry ford) or, a more direct response: the ability to find "drawn together" amusing does not mean you are talented enough to create a similar show yourself, or could even articulate the necessary components/process/etc. Users might know ease-of-use when they see it; they might not be able to describe it beforehand.
There are debtags for this (among other things). You can browse categories, have similar packages for the one you've just installed, (non)popular choices from given category etc.
Just have a look at work being done about this in Debian.
When a user wants to install, say, Firefox?
.tar.gz (or whatever) and install it from a normal user account. Why, oh why, can't a normal user do the same using apt-get or yum or, better (for an inexperienced user) a GUI front-end to these tools, etc.
...$ apt-get install firefox
/var/lib/dpkg/lock - open (13 Permission denied)
.tar.gz as a non-root user. There really isn't a single excuse for making it mandatory for inexperienced user to install such packages as root. It should be optional, letting knowledgeable people only install as root if they decide so.
Not only is it inconvenient, it's also a wide open door screaming "r00t this box" (when people are used to be root to install whatever insignificant app they won't hesitate to install some untrusted binaries as root too).
Experienced user can download Firefox as a
E: Could not open lock file
How fscking brain damaged is this? How many decades will we still have to wait until distro packager get a clue and create a distro where you can easily install, say, Firefox (or Iceweasel, etc.) without needing to be root?
I'm installing Java as a non-root user (something that is impossible under Windows by the way), I'm installing Firefox using the
There is no packaging proglem. THere are many good packaging formats that do exactly whast users need, and easy GUIs to install them. The problem is library inconsistancies between different distros. This is a much harder problem to solve than inadequate package formats. LSB is making progress on this front but i din't think its the solution. If open source projects really want to distribute there software in binary format, then they should just ship all the dependancies with the software. Yes, it would make file sized much larger, but it would be garanteed to work. They could even use an existsing package format like RPM, witch is easy to package, and simple to convert into other package formats.
Has been for quite some time.
Ever since Best Buy, etc. stopped carrying Linux distributions on the shelf.
Autopackage, one of the recent efforts of developers to standardize packaging in GNU/Linux has not been very successful
I always thought Autopackage was a neat idea and a good solution for software projects that wanted to distribute binaries, but didn't want to make 10 different versions for every major revision of every distribution. The major problem I had with Autopackage, though, was integration with the distribution packages. It wouldn't satisfy dependencies with what was already installed, and once a package was installed if it was, say, a library, it in turn couldn't satisfy the dependencies of a distribution package. I know integration with the distribution package management system was planned, but it didn't make it into 1.0, and I think that was a major barrier to its adoption.
CNR is interesting, but I'm not sure why it is considered better than, say, Synaptic, other than that it has a mechanism for paying for commercial software (and maybe it makes it a little easier to find some packages). From what I have read, it seems like it is just a nice frontend on the distributions package management system with a link to some commercial repositories. So I don't see how that can really "solve the problem" of package management on linux.
Only GNU/Linux? You sure you don't mean GNU/XConsortium/OSF/Python/Ruby/everything-else-we -forgot-thats-not-gnu/Linux?
I had the chance to build a small OS that had no GNU anything in it (not even using the compilers), and it felt good to be able to tell people that it wasn't GNU/Linux at all, it was Intel/Sun/Linux.
Taking a note from RISC OS and using AppDirs, this is probably *the* most intuitive packaging system in existence--at least with the current prevalence of the desktop-metaphor user interface. The same concept is also used by Apple and all the NeXTstep derivatives to great effect.
:)
But as usual, never let it be said that a proven and effective mechanism for user interaction would be adopted by the Linux community.
-- Cerebus
It's already automatic for most distros, and if limited to your major apps, no, it wouldn't be a problem. It just doesn't add that much to applications to have included libraries any longer. Mac folks are not freaking out over updates when they get them, are they? Seems to work there with an equivalent modern powerful distro running on similar specced machines on similar connections. And if the maintainers could get just the diffs to upgrade, it would be fast. I know right now on linux when you go for updates, you frequently see the entire application upgraded, yet most of the code is unchanged. right there is an area to work on, upgrade what is only needed, not wipe and replace with mostly the same thing just to get the changes. So in that case, so what if some library needed replacing in multiple locations, if it was only the changed lines of code and not the whole thing it would be smaller than it is today.
I think BSD ports is the best packaging system.
...
And for those who think BSD ported portage
From
http://axljab.homelinux.org/Gentoo
"Since there wasn't anything going on with Gentoo, Daniel switched to FreeBSD. He liked what he saw. Especially the "Ports" system. And he returned to the Linux world. Along with the help of other developers like Achim Gottinger, Gentoo was back on track & charging ahead. The whole package management system was redesigned & called Portage."
Let's name the new cool tool "unipkg". Its purpose is not to create the sixth packaging format, but to easily convert between existing formats, maintain a database of dependencies between other formats' databases of dependencies, ease the instalation from sources (I know, I know, emerge is kewl, etc).
F ORMATS
/tmp, do a default ./configure --prefix=/tmp/unipkg/$PACKAGENAME, make, make check and create a package from /tmp/unipkg/$PACKAGENAME directory. The package should be installed then. Possibly advanced users should be able to customize configure's arguments to fit their system.
/etc/unipkg there should be default (preferred or native) package type (so debian and ubuntu users use debs, fedora, mandriva and suse users use rpm...). If a package is to be installed via unipkg, it would be first converted to system's native (or chosen) format (only if not already in that format) via alien part, and then installed. There should also be a list of mirrors, mirror selection system (like netselect-apt), maybe a list of unwanted formats (for example if we don't like the idea of using slackware's TGZs, since they carry no dependencies info), and some kind of system that would protect the innocent from using "testing" or "unstable" packages.
How would I do that:
1. Get the source of rpm
2. Get the source of dpkg
3. Get the source of... $WHATEVER_IS_USED_TO_PACKAGE_THE_REMAINING_THREE_
4. Get the source of alien
5. Insert a mix of all this stuff into unipkg and add powerful commandline interface, so both rpm and dpkg could be virtually replaced with the new packager.
6. The resulting app should also automatically resolve any dependencies, like yast, aptitude, and many others do. Preferred type of packages should be chosen (rpm, deb, tgz...)
7. Also, there should be a simple compiling interface so you can just
$ unipkg source somestuff-2.13rc1.tar.bz2
and it shall bunzip2 and untar it to
8. In config file
9. This way people could easily install debs on fedora and rpms on ubuntu, all dependencies are resolved, the database is always up-to-date, and everyone's happy =]
10. Now just create a bunch of GUI wrappers. I'm sure both KDE and GNOME teams will create at least a couple of these, and of course an easy CLI tool with ncurses gfx (like cmdline yast or aptitude) would also be kewl.
11. There's still a problem of ABI compatibility, but what would be Linux like without three hours each week spent on repairing stuff =] windows users have to spend even more time on solving other problems which aren't bothering us, so all in all we gain again.
12. There is also a bunch of stuff I don't like, and that (IMHO) should be fixed in some pkg managing systems. e.g. dpkg doesn't care about the dependencies at all, it just installs the package without a word of warning =( One thing I miss is easy and fast instalation of many separate local rpm packages, for example I have downloaded xine and other codecs stuff for suse 10.1, and I have to guess the correct precedence of installing these pkgs instead of doing something like
$ rpm -i libxine*.rpm
The main pro of this solution is that there would be no new package format, but just a common interface for working with existing formats.
The main con is that packages compiled for fedora might screw ubuntu, suse, slackware, etc. up, and vice versa. Maybe some sensitive stuff (like toolchain or some libs) should depend on a virtual package that conflicts with sensitive stuff from other systems.
What about PC-BSDs .pbi files? They work exactly the same way windows .exe or .msi files work. You just double click,they install, and you later have the option of going into a menu and uninstalling. They also use the ports system and so you have the big repository still at your finger tips. It's the best of both worlds in my opinion.
622677120
...for a newcomer in the GNU/Linux world, installing new software is always pretty confusing.In my opinion, the amount and the variety of a software comming with distribution CD and/or from repository is for 99% of potential newcomers more than sufficient. That user will be forever satisfied by any friendly graphical frontend of any packaging system.
Need for more SW --> more clicking. Need for even more SW --> even more clicking. ...even more? ;-)
It's important to remember that the FreeBSD ports tree is a special case of building from source. Many programs are patched by porters to ensure that they will work under the OS; that extra attention isn't all that different from a distro, although the system does allow you to start from a much smaller installed base. Also, building some apps/suites from source is brutally slow; compiling Xorg or Gnome on an old system can take days. In these cases, FreeBSD's own packaging system is extremely handy if somewhat limiting.
Working with Zero Install
davecb5620@gmail.com
The problem I read out from your experience is, that Ubuntu still lacks an intro/welcome screen or manual. Providing good software and a useful environment is pretty shallow, if they don't provide a help system with the minimum "getting start" guide. (I mean, even Windows95 had one!)
Is it possible to give Debian an equivalent of .src.rpm instead of what it has which is. .orig.tar.gz name. .diff file with is using "diff" as an "archive" other things:
.src.deb archive?
1. original archive, with mandatory
2. dsc with some package meta data
3.
more debian package meta data, control files, build scripts
separate diff files.
Can't it be possible to create a
or at least compile (2) and (3) in real archive format (not diff...).
I just compile from source when my preferred package flavor isn't available. With GNU Stow you can cleanly install to /usr/local and keep everything playing nice with existing and future package installs.
I am becoming gerund, destroyer of verbs.
Actually, there's a much easier solution. I'm surprised nobody has yet mentioned it. Perhaps it's not well know.
/usr/include/linux/net.h, the package should just depend on the /usr/include/linux/net.h file that it actually needs. Or if a package needs Python to run, it should depend on a python binary existing in the path, not some python package. If the package requires Python 2.4 or higher, it shouldn't be difficult to check that either. (For example, running python -V will tell you what version you have; the version of the package containing the file should probably match the version of the binary.)
The easy solution is to have packages depend more on FILES, instead of on other packages. So instead of depending on the linux-libc-dev package (under Ubuntu) or the linux-kernel-headers package (under Debian) when I need
I'm pretty certain that DEBs and RPMs can both be made to depend on files. But the feature needs to be used much more, especially for those creating packages to run cross-distro. It would also be helpful to add some other dependency types, like the Python scenario I mentioned about.
Software sucks. Open Source sucks less.
"But I absolutely, 100% do NOT CARE about Linux's "mainstream popularity"."
Keep that in mind next time you all whine that the hardware/software makers aren't supporting you. e.g. wireless/Photoshop. Or that you can't get Linux into your place of employment. e.g. "You should use FOSS instead of that proprietary crap." You want to be a minority? Fine! But don't complain when you have to suffer like a minority.
Recently I decided to try debian again. After installing sarge, I noticed that the software was old ( sorry guys it just is [2005]). So I decided to try something radical. I decided to point my sarge install at ubuntu repositories. First I pointed it at hoary. I ran apt-get update and then apt-get dist-upgrade, and viola. My debian install was now ubuntu. Then I did the same thing moving the system to dapper and then edgy. It is now running xubuntu.
When I had tried to upgrade my fc4 system to fc6 a few weeks ago, rpm couldn't not handle it. Packages did not get installed, the system was in a state of total flux. I had to reinstall FC6 from scratch. Luckily I had my home and important files on seperate filesystems and was able to install the system without loosing any important data. It was much more painful than the debian to ubuntu changes.
So IMHO either dpkg is better or the guys at ubuntu are doing a better job than fedora guys. BTW: Try upgrading a fc system to an equivalant rh system. Last time I tried, you could not.
Oh well. for now I will stick with my fc6 system and xubuntu on my 2 laptops and if in fc7 /fc8 I run into the same issues that I did with fc4-fc6 upgrade, I'll say bye bye fc and hello xubuntu!
Only 'flamers' flame!
Does slashdot hate my posts?
The problem is that there are 'applications' and there are 'system tools' and in linux these are the same. People want to install or use dozens of applications, but there are thousands of system tools (netcat for instance) that might be on a system. In linux these are one and the same, but they are not the same to the user.
.o object files saves significant space.
It wouldn't even take that much more space except that the linux toolchain is really, really bad at making anything stand-alone. Compile a stand-alone "hello world" with GNU libc and it's 700k+. The way libraries are stored in ELF makes it almost impossible to remove functions at link time that are not used; if you link to a library you may have to include the whole thing instead of only the 20% reachable from what your code uses. The build system is at fault too, since often compiling in a single step instead of lots of individual
Basically what I am saying is that there has been virtually no effort at all in linux toward reducing the size of libraries and binaries, so just because a stand-alone program is really large now doesn't mean it would have to be so large. Besides, if the user has 100 applications each taking 10 Mb more from being self-contained, that's only 1gb. That's not a lot of space these days.
I want to install a package that depends on something I have compiled myself, and there's no force install option.
I want to use mirrors to distribute load on the repository servers and have a fallback if one goes down. I can't do this automatically with apt.
Granted, these aren't massive issues, but perfection is a high standard.
I've seen two ways to handle the HD/blue war. a.To make a format that can be read both ways, and b. Make a reader for both. APT (dcpg/.deb) and URPMI (my favorite RPM manager) are both so similar, why doesn't somebody make a middleman manager like URPMI to manage between the two of them. Also, RPMs (I'm more familiar with them) are archives with a script, so somebody should make a package that is an executable, but can generate a primative DEB/RPM script? Two solutions.
The package you reference is actually the Common Lisp interface to the Oracle database.
Help stamp out iliturcy.
I'm with you that it should be easier for the average user to find the software they are looking for, but I have a slightly different approach. I'm a big fan of Synaptic. The first thing I usually do when I open up Synaptic is click the search option and enter a keyword. This keyword is usually a word that describes the function I want the software to perform. For instance, if I was looking for a photo editor, I would type in "photo editor". This brings up a list of packages, sometimes a pretty long one depending on what I've typed in. Then I have the task of scanning through the description column looking for that key word again. The search has brought up packages that all relate to photo editing in some way, but which one is the the actually editor. I want to find the Gimp, not the printer plugin for the Gimp, or just an underly library for it and I certainly don't want just a photo viewer. If my search could then be broken down into categories, this would save me that step. These categories would be decided based on what the function of the package is, whether it is the main package (as in The Gimp) or is it a library, plugin, etc. So my search results now look like this...
Search: "photo editor"
Photo Editors
- GIMP
+Plugins...
+Libraries...
- [other editor]
+Plugins...
+Libraries...
Image Viewers
- ImageMagik
+Plugins...
+Libraries...
- gThumb
+Plugins...
+Libraries...
- kphoto
+Plugins...
+Libraries...
- [other viewer]
+Plugins...
+Libraries...
The preset categories already available when Synaptic (and others like Yumex) starts up are far too broad and require me to either sift through a long list within the category, or even continue drilling down. Worse, I sometimes don't know what category I'm looking for. Is it if I'm editing photos for the fun of it, would that be "Productivity" or "Entertainment"? Moving towards a more search oriented approach is the way to go. That's the way our desktops are now being organized thanks to tools like Google Desktop, Vistas desktop search, and Beagle. My proposed method would help make the search more meaningful. For most of us, we just want the main app, especially the beginners. So we can ignore the thousands of libraries that that app may use. However, for those that might be looking for a specific library, or want to see all of the plugins available for said, app, the list is there to be expanded.
"It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson
Last year I installed OpenSUSE 10.1 on my new home pc with the intention of having a new linux workhorse.
All very fine and dandy. Except the updater that took several minutes of cpu time to figure out I was all up to date...
Downloaded the 10.2 upgrade and intended to use that.
First doh: You seem to be supposed to boot the dvd to do the upgrade.
Second doh: Going to the 64bit version threw me into dependency handling hell. I could _not_ get the installer to shut up or remember my choices about ignoring, deleting, or whatnot for the 300-odd packages it complained about. Abort mission.
Third doh: Boot the 32bit version. "Package so-and-so is locked" it said and showed a single name. Ok, I unlock. Then it repeats that 6-7 times (how about figuring them out all in one go?). Click next. Core dump. Repeatable.
Fourth doh (mostly my own): I forced an install (from Yast I think?). It warned me about not being compatible. It wasn't. After a _lot_ of mucking about with a second install and copying back and forth it booted and thinks it is 10.2. I hope it is.
Fifth doh: The install URLs from 10.1 are still in the list. It somehow let me install an older kernel than the 10.2 one. WTF?
Sixth doh (my own?): I don't get the partitioning limits with primary and extended partitions and MBRs on PCs. I use IDE drives in my Pegasos and "it simply works". OpenSUSE 10.2 really messed with the booting setup. MBR or not, GRUB or not, a gazillion entries in the boot selection, most of them the same.
Seventh doh: I tried upgrading from 32bit 10.2 to 64bit. The install did nothing at all. I guess it thinks that 10.2 is 10.2, no matter what cpu you have...
Eigth doh: The OpenSUSE upgrader now uses more than an hour to check my upgrades. In pure cpu time.
Nineth doh (I forgot this one): I looked for some backup utility to save my hide before I begun all this. What on earth are you supposed to use for a rescue install? Tar?
So this probably shows I'm a bit of a noob in linux handing. Next time someone tests a distro I hope they test it as an _upgrade_ too.
Oh, and to show the other side of the coin; I handle AIX systems at work.
I use TSM SysBack to do a network bootable system backup before upgrades (mksysb to local dvd or tape works just as well).
I transfer or just nfs mount the new filesets for all but the most major upgrades. I commit current filesets, install new ones as applied so I can roll back, do the install while running, and then just reboot.
Painless and _remote_install_ friendly (the servers are 270 kilometers away so that kinda helps).
IBM has even promised no-boot upgrades for the future. This is what I call enterprise class handling. Do not settle for less.
Just create a .tar.gz ... Then you can use alien to convert it to a .deb .
It's a crying shame that AutoPackage is now going the way of the dodo. Heck, if I had the time to learn it I'd package my games in that format. Hearn is right - also, most developers, being techie-minded are still too attached to the .tar.gz method of distribution and leaving binary distribution as an afterthought, usually just chucking out the odd rpm or deb file which is pretty soon horribly outdated. I've not seen many AutoPackaged programs but I updated my aMSN yesterday with it and I just loved it - the way it explains what it's doing, its look, everything.
There's nothing fundamentally wrong with rpm and deb. I can't speak for Slack's TGZ or Gentoo's Emerge because I've never used them, but as I understand it they are frustratingly difficult for beginners to use. RPM and DEB, when implemented well, are extremely easy to use - double click, enter root or sudo password, click install - done. Even easier than Windows. The problem is that people tend to tie RPMs and DEBs to rather exotic dependencies which means that they only tend to work on one version of one distro.
There's other methods too - BitRock (which is free of charge for GPL projects) and Loki Installer (which seems to be the exclusive domain of games, although I see no reason why it can't be applied to serious apps too) are two excellent efforts which really deserve more attention.
Excellent point that
I don't therefore I'm not.