Weekly Edition
Return to the Announcements page
| |||||||||||||
Moblin and Maemo to merge
Intel and Nokia have announced that the Moblin and Maemo projects will be merging into a single mobile platform called MeeGo, which, like Moblin, will be hosted at the Linux Foundation. "MeeGo blends the best of Maemo with the best of Moblin to create an open platform for multiple processor architectures. MeeGo builds on the capabilities of the Moblin core OS and its support for a wide range of device types and reference user experiences, combined with the momentum of Maemo in the mobile industry and the broadly adopted Qt application and UI framework for software developers."
See also: Quim Gil's post on the merger. (Log in to post comments)
Moblin and Maemo to merge Posted Feb 15, 2010 14:21 UTC (Mon) by Baylink (subscriber, #755) [Link]
And the Academy Award for the stupidest, most embarassing name for a new project goes to...
Moblin and Maemo to merge Posted Feb 15, 2010 14:41 UTC (Mon) by Baylink (subscriber, #755) [Link]
And, in other news; don't these project leaders (oh, wait; it's Nokia, who wil just crush them under their boots) ever use the google:
Moblin and Maemo to merge Posted Feb 15, 2010 14:54 UTC (Mon) by smadu2 (subscriber, #54943) [Link]
Meego!
Moblin and Maemo to merge Posted Feb 19, 2010 9:29 UTC (Fri) by v13 (subscriber, #42355) [Link]
Well, maemo came from a password generator [1], so I suspect that meego did
the same thing. It's only that password generators improved over time :-)
[1] http://talk.maemo.org/archive/index.php/t-2994.html
Moblin and Maemo to merge Posted Feb 15, 2010 15:00 UTC (Mon) by mbanck (subscriber, #9035) [Link]
1. They will use RPM, not DEB
2. It will support both arm and x86, initially
3. Not clear what happens to GTK (it's still in the platform overview on http://meego.com/developers/meego-architecture)
4. Not clear what happens to the rest of Maemo, i.e. whether it will just be Moblin with Qt
Moblin and Maemo to merge Posted Feb 15, 2010 15:13 UTC (Mon) by cdamian (subscriber, #1271) [Link]
I think it is great that they join forces.
But I wonder what happens to the nice Moblin GUI.
They also don't really seem to be a good fit. QT / GTK, Debian / Fedora, ...
Moblin and Maemo to merge Posted Feb 15, 2010 15:42 UTC (Mon) by drag (subscriber, #31333) [Link] Really; the most important thing is that they create strong standards that distributions can follow to make it possible for application developers have a strong API to follow. The quality of the API or relative advantages of RPM vs Deb or QT vs GTK is much much less important then having a solid API to follow that you'll know is supported by everybody equally. You would be much more successful building a wooden house on firm ground then a concrete building on shifting sands.for example: I am a big big Debian fan. I prefer it over other distros most of the time. But I would not shed a tear if tomorrow Debian decided to completely abandon the Deb file format and decided to go with RPM. As a end user it would be easier on me to only have to worry about one format. After all; Debian/Ubuntu already support using RPM, it would not be that huge of a leap. It'll be very interesting to see how this turns out.
Moblin and Maemo to merge Posted Feb 15, 2010 15:49 UTC (Mon) by coriordan (guest, #7544) [Link]
DEB / RPM doesn't matter much alright. Debian's system is far better, but it's not because of the package format, it's because they have everything in a single repository.
Pretty much all the package problems I've ever had have come from installing third-party packages. Debian lets me avoid that.
Moblin and Maemo to merge Posted Feb 15, 2010 16:50 UTC (Mon) by drag (subscriber, #31333) [Link]
> Debian's system is far better, but it's not because of the package format,
> it's because they have everything in a single repository.
I always thought it was the concise standards and requirements that they
I have a lot more issues with Ubuntu-specific packages that get made then I
Moblin and Maemo to merge Posted Feb 16, 2010 10:16 UTC (Tue) by johill (subscriber, #25196) [Link]
Which is also irrelevant for Nokia/Intel since they don't use Debian's processes etc., I'd think.
Moblin and Maemo to merge [Offtopic] Posted Feb 15, 2010 16:52 UTC (Mon) by Frej (subscriber, #4165) [Link]
The all-software-in-one-pot is not always the best solution.
For instance, it doesn't really work pr. distribution for 3rd party developers. Also your might wan't
But i guess that's the point of the current systems, it's about being control.
Moblin and Maemo to merge [Offtopic] Posted Feb 15, 2010 17:30 UTC (Mon) by drag (subscriber, #31333) [Link] There is a severe issue to Debian's approach of doing things.(which most people seem to be copying for obvious reasons; there are big benefits... one big one is that Debian's packaging efforts act as a mechanism to get different upstream projects working together... for example OpenAFS requires Kerberos4 for it's protocol.. but everybody else is using krb5. Debian provides a mechanism included with their OpenAFS packages so that people using Krb5 in their orginizations can be backwards compatible and run OpenAFS. Without it users are required to hunt down patches and tools on their own as they are not provided by any kerberos tarballs or Openafs itself (last time I checked)). And that problem is a lack of scalability. Debian package management approach requires a central management team and filtering mechanism. This helps assure high-quality, but the negative aspect of it is that it's a huge bottleneck. It is currently showing strains and it is difficult for people to contribute to Debian and it is difficult to get important updates through Debian's ftp master groups. Simply because there is a lack of reliable manpower. By having upstream people responsible for packages (and having distributors working with them) then you take a centrally-managed mechanism and make it a distributed mechanism. As with anything else distributed approaches to software stuff is inherently scalable. One nice possible nice thing about having a strong standard is that instead of doing './configure; make; make install' we can update the build tools and everything so that you end up with the equivalent of './configure; make; make rpm'. That way you can build a lot of quality control into the actual build system. For example... throw warnings and errors about lack of man pages or documentation; or throw warnings about bad choices in files and directories naming and locations; give errors about conflicts with existing files in the systems belonging to other products, automated dependency detection, etc etc etc. So that with producing Linux software you not only end up with a binary; you end up with a package solution were you can remove/update/add software easily even if you are building from source and that software is more likely to be in compliance with distribution's package policies. Most importantly users don't have to worry about trashing their system if they end up needing to install software that is not available from their distributions.
topic: is Debian's packaging good or bad Posted Feb 15, 2010 22:35 UTC (Mon) by coriordan (guest, #7544) [Link] I disagree with both Frej and drag. To Frej: It does work for 3rd party developers. You put their software in the repository, and then everyone can test for and fix conflicts. Firefox is a good example. Great software, but kinda spoiled by the ban on applying security fixes and improvements (enforced via their trademark rights). If I use Firefox as a 3rd party package, I have to either fix the problem myself (no time) or beg the Mozilla Foundation to make my change (they won't). I much prefer getting my Firefox from Debian (or using GNU IceCat). To drag: "lack of scalability ... huge bottleneck ... currently showing strains" - I remember people saying that ten years ago, when Debian had only a fifth of the packages it has now. How much more scaling and lasting will Debian have to show you? :-) Debian has it's problems, but so does every distro. (The biggest ones are binary blobs in the kernel and hosting the non-free repository)
topic: is Debian's packaging good or bad Posted Feb 15, 2010 22:39 UTC (Mon) by coriordan (guest, #7544) [Link]
Another free-ness problem with Debian is that their version of Firefox (called IceWeasel) recommends that users install non-free addons.
GNU IceCat doesn't, and I just saw that they maintain a list of addons that are free:
Great idea.
topic: is Debian's packaging good or bad Posted Feb 15, 2010 23:49 UTC (Mon) by drag (subscriber, #31333) [Link] To drag: "lack of scalability ... huge bottleneck ... currently showing strains" - I remember people saying that ten years ago, when Debian had only a fifth of the packages it has now. How much more scaling and lasting will Debian have to show you? :-)Until Debian gets a tiny fraction of the level of applications that something like Windows supports then I'll be convinced. Right now Debian is at the miniscule level. Debian was having scalability fractions before and they continue to do so. They never have changed anything to address the problems they were facing. So far just today I was looking around for multimedia applications and found at least 3 open source Linux applications that I wanted to try out and were not provided by Debian. Sure I could compile and install them, but that would take quite literally hours of my time. It is not worth it so I am not going to bother. In fact it's a cronic problem I face every time I want to do something in Linux. I want to play around with Python bindings for Ogre or other gaming engines. Crystalspace integration with Blender. I want to play around with this or try out that. And you know what? At every turn I am forced to figure out dozens of dependencies... many of which conflict with what I have installed or already and I have to download and compile from scratch. Many times I am forced to create chroot trees to try to build and run software in Linux and rarely I am able to figure it out on the first, or even the third try. I have to read wikis, google around on mailing lists, and occasionally give up all hope and seek out a IRC channel for help installing software in Linux. Why? Because every project is different and compiling and installing software is usually something that developers work out for themselves and is not really intended for end users to fart around with. I regularly spend hours trying to get something installed... and I having problems prior to even knowing if the software will solve my problems or even be remotely useable! And you know what? For things like Ogre Python bindings... which multiple times I've spent entire DAYS of my life trying to get working.... Had lovely little windows EXE files that I could of been up and running in MINUTES. That is right. For the majority of people installing software, especially when it comes to any sort of graphics or gaming or anything of that nature, are much better off using Windows to install and play around with open source software then Debian or Fedora or anybody else. No Debian installers. No Debian support. No Fedora support. No nothing. No Linux installation support of any kind besides tarballs. And the current crop of Debian developers are overworked and are now seem to regularly start to drop applications that are of no interest to themselves. The length of the process to get to be a official Debian maintainer is YEARS. Go and look at here: http://www.happypenguin.org/ How many of those are going to get packaged by Debian? How many of those will ever get packaged by anybody? Sure a lot of them are not very good pieces of software and they wont' be around for very long. However if I was using Windows and they built them for Windows I could have fun playing around with them in very short order. However because I am a Linux user I have to sit and fart around with a project for at least a half a hour to get it running, if I ever get it running. THAT is why Debian's repository approach does not scale and will never scale. It's _ALREADY_FAILING_. There is a metric crapload of Linux software that will never get any attention, will never make its way into Ubuntu's repository, will never be made easily avialable to end users. It may be good, or it may not be good. The likelihood of anybody finding out about it is pretty damn small. Debian does a huge amount of work and they do a very good job at what they do. The work they are putting in is critical to the usability that Linux already has. But, especially, when you look at what Fedora, Suse, and everybody else is doing... it's a huge replication of effort that is not really accomplishing anything beyond making installation files for their own specific slice of the user population with very little benefit to anybody else.
topic: is Debian's packaging good or bad Posted Feb 16, 2010 0:11 UTC (Tue) by coriordan (guest, #7544) [Link]
ok. I see your situation.
But, is Debian worse than other GNU/Linux distros? Sounds like a problem they'd all face. Doesn't Debian's large pool of dev packages and libraries at least help in some cases?
topic: is Debian's packaging good or bad Posted Feb 16, 2010 0:14 UTC (Tue) by anselm (subscriber, #2796) [Link] So far just today I was looking around for multimedia applications and found at least 3 open source Linux applications that I wanted to try out and were not provided by Debian. [...] THAT is why Debian's repository approach does not scale and will never scale. It's _ALREADY_FAILING_. There is a metric crapload of Linux software that will never get any attention, will never make its way into Ubuntu's repository, will never be made easily avialable to end users. It may be good, or it may not be good. The likelihood of anybody finding out about it is pretty damn small. Setting up a Debian repository isn't exactly rocket science. What's to keep you (or indeed anybody) from getting together with a bunch of other interested people and packaging that mythical software that the actual Debian developers are too overworked to package for you, if you think it is getting overlooked? It's not as if one needed to be a Debian developer to be able to run one's own repository. (In fact, one doesn't even need to be a Debian developer to package software for Debian. Uploading it to the Debian servers is what requires a Debian developer.) Incidentally, speaking of multimedia software for Debian: There is a very nice semi-official repository at www.debian-multimedia.org that does have quite a number of interesting software packages to do with multimedia.
topic: is Debian's packaging good or bad Posted Feb 16, 2010 0:51 UTC (Tue) by kragil (subscriber, #34373) [Link]
You didn't get it.
There is just too much software and distros and not enough packagers. It
The Linux Foundation really needs to come up with some solution to this
Maybe Meego will help in this regard.
topic: is Debian's packaging good or bad Posted Feb 16, 2010 1:26 UTC (Tue) by coriordan (guest, #7544) [Link]
When thinking about Linux Foundation, remember that although the name might mean something nice to you, it's just a name, and the funding and members of the board comes 85% from of a bunch of proprietary software companies.
In this case, free software has more flexibility than binaries because it can be recompiled to adapt to certain system changes. For the Linux Foundation's members' proprietary software, this benefit is useless, so they'd happily trade it away for crumbs during the setting of standards that help them get the binaries of their proprietary software installed on GNU/Linux systems.
topic: is Debian's packaging good or bad Posted Feb 17, 2010 4:32 UTC (Wed) by rqosa (subscriber, #24136) [Link] > a bunch of proprietary software companies They're primarily hardware companies rather than software companies. Notice that only 1 out of the 6 "Platinum Members" is not a hardware manufacturer (that one is Oracle). > standards that help them get the binaries of their proprietary software installed on GNU/Linux systems. Really? The list of LSB-certified applications includes applications from 4 different companies, and I don't see any of those 4 on the list of Linux Foundation members.
topic: is Debian's packaging good or bad Posted Feb 17, 2010 21:06 UTC (Wed) by nix (subscriber, #2304) [Link]
Of course, Oracle *is* now a hardware manufacturer.
topic: is Debian's packaging good or bad Posted Feb 16, 2010 10:16 UTC (Tue) by Klavs (subscriber, #10563) [Link]
> There is just too much software and distros and not enough packagers. It
> does not scale to the point where all software is packaged for even one > distro. (Debian comes closest, but some games have copyrighted artwork etc. > and those things generally don't help )
Well - IMHO the situation is much like windows. If I want something to be installable on windows - I need to build an installer in an "exe"-package (or use an existing one).
If I want the software installed on debian or derivatives I would create a .deb package - and I could host it in my local repo - it's just as easy (if not more so) than windows packaging.
Also - one could build an RPM instead (installing under /opt would be recommended) - and that could be used by all (since debian has alien).
Either way -you should - package your software - but you don't have to.
topic: is Debian's packaging good or bad Posted Feb 16, 2010 11:07 UTC (Tue) by anselm (subscriber, #2796) [Link] There is just too much software and distros and not enough packagers. It does not scale to the point where all software is packaged for even one distro. Maybe not all software actually needs to be packaged? Debian operates under the assumption that interesting stuff will eventually be packaged. »Interesting« in this context means »interesting to somebody in the position to package it«. For example, I maintain a few packages that probably not a lot of people use, but I do, and so they're in Debian GNU/Linux. If I at some point stop using and maintaining the packages in question, whether they will continue to be part of Debian depends on whether someone else steps up to continue looking after them. This is an application of the principle that free software works best if it scratches somebody's itch. If some software isn't packaged yet that may mean (a) the place it is supposed to scratch doesn't itch anybody badly enough, or (b) the scratching it does doesn't (yet?) provide adequate pain relief. Often new stuff needs to settle down somewhat before it makes sense to package it. Finally, upstream developers who would like to see their stuff packaged are free to do that themselves (and enlist the Debian project's help in getting the packages into the distribution). Hence, so as far as Debian is concerned I don't actually think that there is a problem. One might conceivably ask why we need Red Hat's, Novell/SUSE's, and Mandriva's similar-but-separate offerings in the RPM-based distribution area, but then again it is as well to remember that these three are, unlike the Debian project, all commercial competitors who are understandably reluctant to throw their lot in with each other. (That was actually tried a number of years ago -- remember UnitedLinux? -- and didn't get anybody anywhere.)
topic: is Debian's packaging good or bad Posted Feb 17, 2010 2:48 UTC (Wed) by rqosa (subscriber, #24136) [Link] > There is just too much software and distros and not enough packagers. It does not scale to the point where all software is packaged for even one distro. You might be interested in Arch Linux's Arch User Repository. This is a collection of user-contributed/maintained build scripts (PKGBUILDs) which can be used to build Arch packages. PKGBUILDs are fairly small and easy to develop: see one for MPlayer here. (Of course, a user building packages from the AUR should review the PKGBUILD and .install file if there is one for malicious code before building/installing.) The AUR web site is currently reporting that there are 19946 such packages in AUR (not counting ones that have been adopted into [community]).
topic: is Debian's packaging good or bad Posted Feb 17, 2010 1:57 UTC (Wed) by rqosa (subscriber, #24136) [Link] > For the majority of people installing software, especially when it comes to any sort of graphics or gaming or anything of that nature, are much better off using Windows to install and play around with open source software then Debian or Fedora or anybody else. The main reason for that is probably just that there are more installations of Windows (on desktop and notebook computers at least) than there are of Linux distributions, so an app developer can get more users by building an installable package for Windows than by doing the same for Linux. (And also, building an installable package is basically the only way to get Windows users to use the software, because build tools aren't included with Windows.) However, building such installable packages is a major pain for developers, because they have to package all library dependencies with their software (except for ones provided by Windows itself) and provide their own updater mechanism, so you have one updater for Firefox, another for VLC media player, another for OpenOffice, etc... Is there any real reason why developers can't do the same for Linux (bundle all the dependencies with the application)? I don't think there's anything stopping them. The LSB is even supposed to provide a set of library ABIs which a program can depend on without having the libraries packaged with it. Yet, it seems like hardly any developers care to build their apps for the LSB, for some reason... (The Linux Foundation has also built a few example LSB packages of free apps here.)
topic: is Debian's packaging good or bad Posted Feb 17, 2010 2:09 UTC (Wed) by rqosa (subscriber, #24136) [Link] > bundle all the dependencies with the application Or, use static linkage. (In the case of libraries which are normally dlopened, use Libtool's "Dlpreopening" capability.)
Applications not packaged by the distribution Posted Feb 20, 2010 17:42 UTC (Sat) by anton (guest, #25547) [Link] Yes, it can be quite a bit of work to install some applications (and all the supporting libraries etc.) from source. E.g., it can already take some time to figure out where to get the source from, and then whether to use the source repository head or the released package. One may not want to go to these lengths before knowing that the application is actually worth it.One example was when I wanted to see if the new version of hugin was better than what was available through Debian at the time. I did not want to work for half an hour or an hour to try that out, so I downloaded and tried the Windows version, because that was much simpler to install. Only when I knew that it was worthwhile did I invest that effort. Why was the Windows version simpler to install? Mainly because Windows is a less featureful system, where basically every application package has to do everything for itself, and it's therefore not considered improper for an application package to install all kinds of shared libraries that a more sophisticated system would have as a separate package. The other reason is that there is only one Windows version, whereas there would be one Linux package per distribution. We could do the same for Linux, but then we would distribute tar packages with everything (including possibly outdated libraries) included, or maybe with statically linked binaries. We don't want that for packages (at least package versions) supported by our distribution, because this approach has a number of disadvantages. But maybe it (or some other cross-distribution approach) would be appropriate for the applications that are not supported by all distributions. That brings up the following idea in my mind: A cross-distribution package system (so packaging can be shared between distributions) that downloads sources and builds and installs them (to /usr/local or somesuch) mostly automatically. Maybe with an option for binary packages. Dependencies on libraries or programs provided with the distribution would be tricky, but it may be possible to satisfy them with Debian's "apt-file search" or similar functionality. Building from source would avoid most ABI problems and would allow supporting many different hardware platforms, and allow the user to use the latest code without the packager having to upgrade the package for every source update (of course there will be some cases where the package will not work with the new sources, then the package will have to fall back to a known-good source, or the user has to install in the old-fashioned way). Such a system would provide a rougher experience than the distribution's system (more frequent failure or breakage, not necessarily clean deinstallation), but it's better than having to do the installation manually (with the same disadvantages).
topic: is Debian's packaging good or bad Posted Feb 16, 2010 8:52 UTC (Tue) by roc (subscriber, #30627) [Link]
> Great software, but kinda spoiled by the ban on applying security fixes
> and improvements (enforced via their trademark rights)
Have you got an actual example of Mozilla ever denying usage of the trademark because they rejected a security fix or a genuine improvement?
topic: is Debian's packaging good or bad Posted Feb 16, 2010 10:22 UTC (Tue) by Klavs (subscriber, #10563) [Link]
Well - iceweasel was the result of Mozilla NOT allowing Debian to backport security fixes to older Firefox releases - and still calling it Firefox.
Also the artwork isn't free - that also made it un-shippable by Debian (except in non-free I guess).
They needed to do this, to support their stable distribution - as everyone does.
topic: is Debian's packaging good or bad Posted Feb 16, 2010 11:50 UTC (Tue) by coriordan (guest, #7544) [Link]
No. The distros I follow (Debian and gNewSense) rejected Mozilla Foundation's system, so I haven't heard of any rejects within that system.
Fedora might provide an example? Or Ubuntu? Or Debian pre-rebranding? I haven't looked into it.
Moblin and Maemo to merge Posted Feb 15, 2010 17:36 UTC (Mon) by xav (guest, #18536) [Link]
I'm also a bit sad about the Qt choice - a bit too much developing behind closed doors for me. It's very understandable from the Nokia point-of-view (they bought Trolltech), but after all Intel and Nokia invested in various GObject-based systems, I was hoping to see a solid and widespread platform emerging.
So go my hopes. Let's try to rejoice anyway, it's still Linux under the hood.
Moblin and Maemo to merge Posted Feb 15, 2010 21:19 UTC (Mon) by Adi (guest, #52678) [Link]
Why do think it's behind closed doors?
Qt is licensed under LGPL, they have public repository, they accept patches and contributions from external developers too.
Moblin and Maemo to merge Posted Feb 16, 2010 15:23 UTC (Tue) by robert_s (subscriber, #42402) [Link]
"a bit too much developing behind closed doors for me"
Moblin and Maemo to merge Posted Feb 16, 2010 20:30 UTC (Tue) by coriordan (guest, #7544) [Link]
I know nothing about Qt, but I would point out that online source doesn't stop a project being "closed door".
There are issues such as where the decisions are made, how easy it is to become a core member, and whether you can ever become an equal member of the dev team.
Moblin and Maemo to merge Posted Feb 16, 2010 21:31 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
If you know nothing, how about educating yourself a bit before pointing
out things?
Moblin and Maemo to merge Posted Feb 17, 2010 7:54 UTC (Wed) by xav (guest, #18536) [Link]
Qt is indeed developped behind closed doors.
You can submit patches to fix some bugs if you want, but the whole design process happens at Trolltech, and you can't discuss it.
what posts are appropriate for LWN Posted Feb 21, 2010 14:09 UTC (Sun) by pjm (subscriber, #2080) [Link]
I'm guessing that boudewijn's comment is because he interpret's coriordan's post as a claim that Qt is a closed-door project; is that correct?
Whereas I interpret the I know nothing about Qt disclaimer as a deliberate (yet failed?) attempt to avoid the appearance of claiming that Qt is a closed-door project.
robert_s's terse post appeared to present the existence of a publicly-readable source-code repository as disproving that [Qt is] a bit too much developing behind closed doors. [This may or may not be robert_s's intention, and robert_s may or may not be right: indeed, it depends on how one interprets developing behind closed doors.]
coriordan responded with what might either be described as pointing out a flaw in logic or pointing out what he sees as a more relevant/important meaning of developing behind closed doors. In either case, I consider it a useful contribution to the discussion even if he doesn't know how Qt rates by the metrics that he proposes (so long as he's clear about not making claims as to how Qt rates, see my first two paragraphs on this point).
For anyone that is educated about Qt, an appropriate response to coriordan's post would be to share that education by providing information about how Qt rates by those metrics.
I make this post not to defend an individual post from someone I don't know, but rather because I very much want to encourage posts that either explore useful criteria for openness or that draw attention to missing premises even if one isn't certain whether or not those premises are true.
Moblin and Maemo to merge Posted Feb 15, 2010 15:32 UTC (Mon) by drag (subscriber, #31333) [Link]
Wow. I mean seriously... holyshit.
This is the most sane thing that I have ever seen happened. Good for these
Moblin and Maemo to merge Posted Feb 15, 2010 15:38 UTC (Mon) by xxiao (subscriber, #9631) [Link]
wow, interesting to watch.
maybe they think that's the only way to compete with android? it will be based on RPM, sigh.
Moblin and Maemo to merge Posted Feb 15, 2010 15:45 UTC (Mon) by niner (subscriber, #26151) [Link]
You know, it's the year 2010. rpm cought up with deb quite some time ago
and does have it's own advantages on top of that.
Moblin and Maemo to merge Posted Feb 15, 2010 16:10 UTC (Mon) by xxiao (subscriber, #9631) [Link]
After Redhat dumped me as a desktop user years ago I rarely looked back...what's new on rpm comparing to deb these days?
Moblin used to be ubuntu/debian-based, then switched to Fedora, not sure what happened behind the scene then,maybe ubuntu was too closely tied with google? a wild guess.
Moblin and Maemo to merge Posted Feb 15, 2010 16:30 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Not sure what you thought was actually missing in the format since your
comments on it are rather vague but for what's new on rpm visit
Moblin and Maemo to merge Posted Feb 15, 2010 16:47 UTC (Mon) by pranith (subscriber, #53092) [Link]
May be you could help a little better by pointing out where the relative advantages of rpm over deb are?
Moblin and Maemo to merge Posted Feb 15, 2010 17:06 UTC (Mon) by drag (subscriber, #31333) [Link] The advantages of RPM over Deb is that RPM is already a established LSB standard that everybody already supports. Ubuntu supports it, Debian supports it, Redhat, Suse, Fedora, Mandriva, etc etc.Fundamentally there is very very little you need beyond just a tarball when it comes to installing and removing software. Slackware it's assorted third party projects management tools show that. It is really is irrelevant the relative pluses and minuses when faced with the huge positives of having users and programmers only being forced to deal with one format. Either format is perfectly capable of performing the job at hand and that is the #1 one thing to keep in mind. -------------------- If you want a plus with RPM, which I think is a big big plus; RPM is designed to allow hands-off upgrading of software. Deb is not. Deb requires a administrator be sitting on a shell during the upgrade and baby sit the installation and upgrading of software. It is NEVER a good idea to automate a cron job to perform a upgrade on a Debian-based system. The only proper way to perform a fully automated upgrade on a Debian machine is if you already have done it and can pre-configure any questions that come up; most likely in combination with a private debian mirror were you can control the upgrades and a configuration engine like Puppet or CFengine to provide the configuration files and management mechanisms. RPM and Redhat's tools, on the other hand, are designed to be upgradeable without human intervention. This is a HUGE advantage for a few different reasons. Chief among them is that the more effort you require to be put into a upgrade the less likely people will do the upgrade. For Linux it is critical that you keep your system up to date in order to have a secure system. If you provide a fully automated way to do upgrades then you can activate it by default and end users will much more likely be kept safe from external attackers. This is currently a very difficult problem... most EEEPC Linux users, for example, are probably still floating around with a remote exploit in their Samba versions unless they made the upgrade to Windows or Ubuntu. -------------------- Now the RPM supported in LSB is not quite the same as the RPM native to Redhat (and others). Their RPM is based on older revisions and desperately needs updating. So there is a lot of room for improvement in this. Especially when it comes to user-friendly mechanisms like Packagekit.
Moblin and Maemo to merge Posted Feb 15, 2010 17:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
"If you want a plus with RPM, which I think is a big big plus; RPM is designed to allow hands-off upgrading of software. Deb is not."
Patently not true. Dpkg by default uses medium prompt level, but it can be overridden. Also, debconf allows to script all answers and has nice GUI integration.
Moblin and Maemo to merge Posted Feb 16, 2010 14:33 UTC (Tue) by zlynx (subscriber, #2285) [Link]
Yes, that's what he said. If you've done it before and know all the answers...
It is also my experience that if you turn off the prompting in Debian and just do the deb installs, the system will in general end up horribly broken and require much fixing.
I've had my Fedora installs running automatic nightly updates for years now without major problems.
Moblin and Maemo to merge Posted Feb 16, 2010 16:15 UTC (Tue) by foom (subscriber, #14868) [Link]
I do auto upgrades with debian. It works fine for stable/security updates. They don't make
massive changes in stable updates, so there's little that could go wrong. I wouldn't recommend using this for upgrading from one distro version to another, though -- skipping all questions and using only old config files is quite likely to get you into trouble.
Anyhow, the following shell fragment is what I use.
DEBIAN_PRIORITY says only ask critical questions. DEBIAN_FRONTEND makes it not ask the user
All the -o Dir::Etc lines are to make it use a different sources.list file for the auto-updates (in
Dpkg::Options::="--force-confold" makes it not prompt what to do about modified
-y answers yes to all apt-get questions.
auto_apt_get () {
auto_apt_get update
Moblin and Maemo to merge Posted Mar 2, 2010 12:57 UTC (Tue) by nye (guest, #51576) [Link]
Thanks for posting this. The separate sources list in particular is a nice detail.
Moblin and Maemo to merge Posted Feb 15, 2010 18:19 UTC (Mon) by anselm (subscriber, #2796) [Link] For the record, LSB does not mandate RPM as the base package installation tool of a compliant system. It just says the system must be able to install packages that third-party vendors provide in RPM format, which is a completely different thing. Also it is not necessary to interact with dpkg as it installs packages. This can be avoided, e.g., by »pre-seeding« Debconf with the answers to the questions it would otherwise ask the user. Finally, one must keep in mind that this sort of thing is rarely if ever decided solely based on the technical merits of the solutions involved. Instead it is safe to assume that when the Moblin and Maemo guys sat down to figure out how to merge their systems, they had to adopt parts of both just to keep everyone happy. (After all, everyone had been sinking so much work into their stuff, it would have been a pity to throw one away completely.) One might conjecture, for example, that the Maemo guys got to hang on to Qt as the main GUI toolkit while the Moblin guys got to hang on to Fedora as the base distribution, so both parties could save face and meet in the middle :^)
Moblin and Maemo to merge Posted Feb 15, 2010 19:09 UTC (Mon) by drag (subscriber, #31333) [Link] This can be avoided, e.g., by »pre-seeding« Debconf with the answers to the questions it would otherwise ask the user.Yeah. That is what I said. You need to know the answers and have a way to pre-configure them. (to the OP) And sure Dkpg can be configured to ignore all but the most critical questions, but it still does not really change the fundamental nature of the beast. And they were asking about a technical advantage and this is certainly one of them. Finally, one must keep in mind that this sort of thing is rarely if ever decided solely based on the technical merits of the solutions involved. Instead it is safe to assume that when the Moblin and Maemo guys sat down to figure out how to merge their systems, they had to adopt parts of both just to keep everyone happy. Moblin is a part of Linuxfoundation.org. One would hope that they would try to keep their standards compliant with one another. That seems to be important. It is not so much a distribution as it is a project to bring uniformity to Intel-based mobile Linux systems. With the addition of Maemo now they are trying to get everything cross- platform. Whether or not Dpkg or RPM is superior to one another is really very irrelevant.
Moblin and Maemo to merge Posted Feb 15, 2010 20:56 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
Its instructive to go back to the commentary made when Moblin switched to rpm when they opened up moblin v2 development. Dirk Hohndel specifically commented on the availability of the licensing header tag fields in the rpm format as a reason for the change. The stated reasons are boring, pragmatic, build system specific technical reasons related to the type of build environment desired when they were restructuring for moblinv2.
---
I do find it fascinating though that the Moblin/MeeGo choice of RPM/DEB is still contentious, but the Google move from Deb to using Gentoo's portage system for ChromeOS development hasn't generated as much...passion...from the peanut gallery.
Considering the sort of use specific device targets MeeGo is being designed for.. i would have thought that either conary or portage would have been the most, apt, infrastructure technology for the same reasons that Google has moved on to using portage.
-jef
Moblin and Maemo to merge Posted Feb 15, 2010 21:46 UTC (Mon) by foom (subscriber, #14868) [Link]
> I do find it fascinating though that the Moblin/MeeGo choice of RPM/DEB is still contentious,
> but the Google move from Deb to using Gentoo's portage system for ChromeOS development > hasn't generated as much...passion...from the peanut gallery.
I suspect a lot more people use and care about Moblin than ChromeOS. No point in getting
Moblin and Maemo to merge Posted Feb 15, 2010 23:23 UTC (Mon) by anselm (subscriber, #2796) [Link] Dirk Hohndel specifically commented on the availability of the licensing header tag fields in the rpm format as a reason for the change. This is a bit of a straw man considering that it would be trivial to add the same sort of information to a .deb package. You might not actually even need a »License:« header for it; a »licensed::gpl« (or whatever) entry in the »Tag:« header would probably be sufficient already. Dirk Hohndel is too smart to get away with something like this. The reason why Debian doesn't do this already is that for Debian GNU/Linux itself, it isn't necessary to put that sort of information in the package file header; the distribution places everything that is free (according to Debian's definition of »free«, the DFSG) in the »main« part of the distribution while everything that does not meet the DFSG either directly or by association goes to »non-free« or »contrib«, respectively. There is no apparent need to specify the licensing of a package in more detail unless you want to get anal-retentive about BSD vs. GPL licensing or some such; as far as Debian GNU/Linux is concerned, everything in »main« is »free enough«. In Debian packages, more detailed licensing information is provided in the mandatory »copyright« file, and indeed for a majority of packages a »License:« header could probably be populated automatically from the content of the »copyright« file. Of course, having an explicit »License:« header in Debian packages would make a lot of sense in the greater scheme of things, and it seems such a straightforward thing to add that it could hardly be considered a deal-breaker. In fact I find it hard to believe that that was supposed to be the real reason for the switch, but then again what do I know?
Moblin and Maemo to merge Posted Feb 16, 2010 1:14 UTC (Tue) by ewan (subscriber, #5533) [Link] There is no apparent need to specify the licensing of a package in more detail unless you want to get anal-retentive about BSD vs. GPL licensing or some suchI would argue that the case of GPLv3 software in particular shows the need for finer granularity; it's quite possible now to have two chunks of code that are each DFSG-free, but that may not be linked together. That's a useful thing to be able to detect programmatically.
Moblin and Maemo to merge Posted Feb 16, 2010 5:58 UTC (Tue) by foom (subscriber, #14868) [Link]
Indeed. See the recent thread [1] where a debian developer noticed that some GPL'd software was
inadvertently being linked against OpenSSL (gpl-incompatible!).
There is a proposal for Debian to make the debian/copyright files be machine readable for just this
[1] http://lists.debian.org/debian-devel/2010/01/msg00354.html
Moblin and Maemo to merge Posted Feb 15, 2010 17:23 UTC (Mon) by niner (subscriber, #26151) [Link]
A good example is real architecture support: I can install any 32 Bit rpm
on my x86_64 system and get all the dependencies correctly resolved, because the package manager actually knows about architectures.
When the 64 Bit stuff came up I just cross-graded my system and have done
Moblin and Maemo to merge Posted Feb 15, 2010 17:29 UTC (Mon) by xav (guest, #18536) [Link]
Other point of superiority for RPM: your system is always clean, because as the RPM database is always going to be corrupted after a while (as soon as you enable a third-party repository), you have to reinstall from scratch.
OTOH DEB systems last for years so you have no excuse for starting afresh.
Yes I know it's a bit harsh, but all of my RPM systems ended like that, whereas I got no problem with DEB systems.
Moblin and Maemo to merge Posted Feb 15, 2010 17:37 UTC (Mon) by drag (subscriber, #31333) [Link]
Yeah.. while the rpm format itself is nice, the tools for managing deb files
(dpkg, apt-get, etc) and undoubtedly faster, more mature, and more stable.
But these sort of issues are fixable.
Moblin and Maemo to merge Posted Feb 15, 2010 17:56 UTC (Mon) by niner (subscriber, #26151) [Link]
Again: have been. Nowadays tools like zypper are easier to use, faster (!)
and have more features.
Moblin and Maemo to merge Posted Feb 15, 2010 19:15 UTC (Mon) by drag (subscriber, #31333) [Link]
Yeah.. if your using OpenSuse. Not terribly useful for anybody else at this
point. Maybe if it gets included as part of the new MeeGo standard then it may be. :)
Moblin and Maemo to merge Posted Feb 18, 2010 2:15 UTC (Thu) by vonbrand (subscriber, #4458) [Link] It has been quite a long time since an RPM database got corrupted here (Fedora, rawhide with its large churn + some third party repos + homebrewn packages for good measure). The switch to a more resilient Berkeley DB version really shows...
Moblin and Maemo to merge Posted Feb 18, 2010 8:56 UTC (Thu) by xav (guest, #18536) [Link]
Yes, I should be clearer: the corrupted database syndrome, while frequent in the past, is now rare. What happens most, is that you can enter in a state with broken dependencies or something like that, where you can't upgrade your packages nor install/remove anything. I often see that with RHEL or Fedora machines, and I've grown to fear that.
Moblin and Maemo to merge Posted Feb 18, 2010 10:03 UTC (Thu) by Cato (subscriber, #7643) [Link]
Any corruption of the RPM database (that can't be automatically repaired) is quite scary for a mobile phone, where the user will have no chance of repairing this. A full reformat and reinstall of all apps will be needed - can only hope they have separate data backups, as a full system restore might simply recover the corrupt RPM database.
Not sure how APT/dpkg compares here, I've seen some reports of dpkg corruption that were easily recoverable from.
Moblin and Maemo to merge Posted Feb 18, 2010 10:58 UTC (Thu) by michich (subscriber, #17902) [Link]
I don't remember a situation like that ever happening to me on Fedora. I'm curious, what do error messages look like in such a situation?
On the other hand, I have encountered a situation like this on Debian where errors during the configuring stage of installing a package caused apt-get to stop and then it refused to install new packages or remove the affected packages.
Moblin and Maemo to merge Posted Feb 18, 2010 12:57 UTC (Thu) by xav (guest, #18536) [Link]
Sorry, I don't have a Fedora system at hand.
On an RHEL 5.3 I have some of these: Error: Missing Dependency: libx264.so.60()(64bit) is needed by package gstreamer-plugins-bad-0.10.8-4.el5.1.x86_64 (installed)
(I didn't instal anything by hand, all through yum).
Moblin and Maemo to merge Posted Feb 18, 2010 13:01 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Since EL doesn't even include this package and you must have installed it
via a third party repository its probably a breakage related to them and has nothing to do with RPM itself
Moblin and Maemo to merge Posted Feb 18, 2010 14:07 UTC (Thu) by xav (guest, #18536) [Link]
Whatever. Installing from the widely used repository for multimedia addons shouldn't break the system. On a debian systeem it doesn't. On my N900 it doesn't. On Fedora the desktop didn't even work (nautilus stuck waiting in GIO).
Moblin and Maemo to merge Posted Feb 18, 2010 14:35 UTC (Thu) by michich (subscriber, #17902) [Link] Installing from the widely used repository for multimedia addons shouldn't break the system. On a debian systeem it doesn't. On my N900 it doesn't.On my Fedora it doesn't either. And on Fedoras of any other Fedora users I know. On Fedora the desktop didn't even work (nautilus stuck waiting in GIO).I have no idea what could cause such a problem, but it's likely unrelated to RPM.
Moblin and Maemo to merge Posted Feb 18, 2010 14:21 UTC (Thu) by michich (subscriber, #17902) [Link] I don't see how a missing dependency in the installed set would prevent the installation of new packages. I tried to reproduce (installed gstreamer-plugins-bad from rpmfusion on RHEL5.4, then forced the removal of x264-libs with You should definitely be able to either remove the package with the missing dependency, or use If none of this helps, I'd like to see a more complete bug report.
Moblin and Maemo to merge Posted Feb 16, 2010 14:54 UTC (Tue) by wookey (subscriber, #5501) [Link] A good example is real architecture support. I can install any 32 Bit rpm on my x86_64 system and get all the dependencies correctly resolved, because the package manager actually knows about architectures.. A very good point, but it's only fair to point at that this coolness was achieved at the expense of generality. Unless I am hopelessly out of date the rpm package management tools/packaging rules only deal with the 32/64 bit case for one arch, they do not deal with multi-architecture installs in general. The (admittedly very slow in arrival, but due in the next Debian stable) Debian version of architecture support is rather more complete in that you can install any set of architecture libraries side-by-side, and extensions for development packages are being produced as we speak which makes cross-installing for cross-building into something the native package management tools deal with as a matter of course. I hope and expect that (after a certain amount of conversion pain) this will make all sorts of cross-development tasks much easier than they have been to date, as well as allowing the easy installation of library dependencies for runtime-compatible architectures, as has been available elsewhere for a while. Extending the mechanism to binaries for other cool stuff like running foregn binaries under emulation is also possible, but one thing at a time... See https://wiki.ubuntu.com/MultiarchSpec and https://wiki.ubuntu.com/MultiarchCross for the sordid details.
Moblin and Maemo to merge Posted Feb 16, 2010 18:53 UTC (Tue) by niner (subscriber, #26151) [Link]
I think you're out of date. The arch_compat entries in rpmrc define
architecture compatibilities.
For example the x86_64/i386 compatibility is defined by:
arch_compat: x86_64: amd64 em64t athlon noarch
This is the reason why I can happily install .x86_64, .i586 and .noarch
Moblin and Maemo to merge Posted Feb 16, 2010 19:08 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
If you want another prominent example there is no automatic debug info
packages in Debian yet and that has been there for years in RPM but such comparisons usually miss the point that packaging formats are not that interesting anymore for any modern platform
Moblin and Maemo to merge Posted Feb 16, 2010 23:04 UTC (Tue) by foom (subscriber, #14868) [Link]
On the other hand, there are automatic debug packages in Ubuntu (also using same deb format).
But, I agree: that's one really annoying thing about Debian. I don't know what the holdup is, they
Moblin and Maemo to merge Posted Feb 16, 2010 19:42 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
I don't see any way for the existing compat system to deal with installing, say, an arm library on an
x86 system without causing file conflicts.
Moblin and Maemo to merge Posted Feb 15, 2010 16:52 UTC (Mon) by dmaxwell (guest, #14010) [Link]
I could care less about the merits of deb versus rpm per se. But what I do like about deb based distros is they all inherit the integration work and dependency packaging standards of Debian. I have yet to see an rpm repo that is comparable to depth and quality of say a Debian Testing repo. A major reason for this is that rpm distros have a much larger tendency to go their own way. Mandriva, SuSe, and RedHat family distros are all separate universes of packages where even source packages don't easily port from one to another. The version and name skew of package dependencies can be quite large.
Deb based distros all start with a version of a Debian repo so I can do things like rebuild an Ubuntu package on Debian or vice versa and the gymnastics required to make this work are usually minimal. For instance, the latest SpamAssassin is available in Debian Unstable and I built and installed it on a Lenny based email gateway easily.
My fear is that now that MeeGo is rpm based, it will be yet another separate universe of packages that will be harder to port things to. Maemo as a deb based platform was much more exciting to me because of the minimal effort to make damn near anything available to a Debian based distro work on it.
Moblin and Maemo to merge Posted Feb 15, 2010 21:28 UTC (Mon) by buchanmilne (guest, #42315) [Link] I have yet to see an rpm repo that is comparable to depth and quality of say a Debian Testing repo. How hard have you looked? More packages doesn't always mean the user will find what he wants. Sure, Debian may have more text editors, but does it have an easy-to-use free-software HTPC media player. No (sure, a PPA is available for Ubuntu, but I can't find xbmc in debian). Mandriva does.(Ok, so I chose some non-server-related software that has been in Mandriva for only a few weeks, after a Mandriva contributor submitted patches upstream to make it Free Software, but I have been using the Mandriva 2010.0 backport package for a week, and it is great. And, I am aware of a number of other instances where Mandriva supplies a package, and Debian does not, including some server-targeted software. I have had trouble supporting Debian servers in enterprise environments because they were lacking packages I needed, and which were available for CentOS and other RPM-based distros)
Mandriva, SuSe, and RedHat family distros are all separate universes of packages where even source packages don't easily port from one to another. There are some minor incompatibilities, mostly:
There are other more minor issues, but SRPMS are actually relatively compatible. For example, the Mandriva openldap package (of which I am the maintainer) rebuilds almost perfectly (there is a small issue with Fedora having shipped tcp_wrappers headers in the tcp_wrappers package, which didn't have a tcp_wrappers-devel or similar provides, affecting everything up to Fedora 11 which require the horror of "--nodeps" at build time) on Fedora and Red Hat/CentOS (assuming the required macros compat file is in place). Most typical packages are a lot less complex than that ... I have also in the past built cross-distro SRPMS on Solaris (with rpm), allowing me to have a single source and package building toolchain. Adapting to Solaris (and limited option ordering, option availability in Solaris versions of useradd etc.) was quite trivial. (Once RPMS were built, a simple perl or sh script extracted the files from the RPM to a fake root to use with pkgmk etc. to create a real Solaris package, with RPM's %postinstall scripts etc. migrated to the Solaris package).
For instance, the latest SpamAssassin is available in Debian Unstable and I built and installed it on a Lenny based email gateway easily. Last I checked, spamassassin was relatively trivial. In my previous role at work, I rebuilt a few hundred Mandriva SRPMS for RHEL3/RHEL4/RHEL5, and really had very few problems. Granted, I was using a macro compat file, but more time was spent working through build dependency chains (build, fails, build buildrequires, fails due to missing buildrequires ...). And no, the packages in question were not significantly represented in Debian ... some are now, but then they are also now in Fedora and some are in EPEL for RHEL5.
My fear is that now that MeeGo is rpm based, it will be yet another separate universe of packages that will be harder to port things to.If anything, it would have been that there were existing ports (e.g. to arm). However, at least one of the RPM-based distros you mentioned has an arm port, however there isn't much public information on it, so I am not sure how much of the distro is in the port ... However, having less actual code duplication (e.g. if Nokia adds MMS support to Maemo, in the past would Intel have written their own?) should result in a more comprehensive platform for real (non-geek) users of open phones and other embedded devices with user interfaces sooner than later. And, at this point, I fear later may be too late.
Moblin and Maemo to merge Posted Feb 16, 2010 3:25 UTC (Tue) by TRS-80 (subscriber, #1804) [Link] Debian Multimedia just started packaging XBMC.The GNOME packagers in Solaris have a script called pkgbuild that makes native packages from RPMs.
Moblin and Maemo to merge Posted Feb 15, 2010 16:50 UTC (Mon) by Janne (guest, #40891) [Link]
"it will be based on RPM, sigh."
What's wrong with RPM? Could you detail your objections to it?
I bet that your objections towards RPM and preferences towards DEB are not about the package-
Moblin and Maemo to merge Posted Feb 15, 2010 16:59 UTC (Mon) by xxiao (subscriber, #9631) [Link]
oh when I say deb i mean apt-get/aptitude/deb as a whole.
I had pretty bad user experience with rpm(dependency hell,etc), as simple as that. With deb so far my experience is superior. One month ago a new linux user on a LUG mailing list wanted to remove openssl from Fedora(not sure why he wanted that), without hints from the system he hit the return key, which removed a lot of other packages and made his system totally unusable(and unrecoverable). in debian/ubuntu you will get a clear/terrifying list of packages that will be affected before you hit the return key... a bad experience for him I guess.
Moblin and Maemo to merge Posted Feb 15, 2010 17:43 UTC (Mon) by nye (guest, #51576) [Link]
Not to mention the zillions of other differences which are technically orthogonal to the choice of package format, but in practice go hand in hand. This includes things like the tools used to work with them (obviously), package naming conventions, different packaging choices (paths, compile-time options, distribution patching), the way initscripts work, potentially differences in the ways the software is configured, etc.
None of these things necessarily are any better with one than the other, but it's a major change which is typically frustrating for the user.
Moblin and Maemo to merge Posted Feb 15, 2010 18:18 UTC (Mon) by michich (subscriber, #17902) [Link] $ LANG=C sudo yum remove openssl
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package openssl.x86_64 0:1.0.0-0.13.beta4.fc12 set to be erased
--> Processing Dependency: libcrypto.so.10()(64bit) for package:
trousers-0.3.1-19.fc12.x86_64
[... cut about 2000 lines of dependency output ...]
--> Finished Dependency Resolution
Dependencies Resolved
====================================================================
Package Arch Version Repository Size
====================================================================
Removing:
openssl x86_64 1.0.0-0.13.beta4.fc12 installed 3.5 M
Removing for dependencies:
GConf2 x86_64 2.28.0-4.fc12 installed 5.8 M
[... cut about 800 lines long list of packages ...]
Transaction Summary
====================================================================
Remove 809 Package(s)
Reinstall 0 Package(s)
Downgrade 0 Package(s)
Is this ok [y/N]:
The hint looks quite obvious to me. And if you just hit Enter, the default is to do nothing.
Moblin and Maemo to merge Posted Feb 15, 2010 23:35 UTC (Mon) by proski (subscriber, #104) [Link]
As far as I know, future versions of rpm will save "soft dependencies", which should reduce the number of hard dependencies that lead to such rigidity. In any case, I don't think it's a big deal for MeeGo.
Moblin and Maemo to merge Posted Feb 16, 2010 3:26 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
which fork of rpm is going to gain this capability?
remember that right now there are 4-5 separate forks of the rpm tools.
Moblin and Maemo to merge Posted Feb 16, 2010 14:30 UTC (Tue) by skvidal (subscriber, #3094) [Link]
There's only one branch of rpm that any major distro uses.
rpm.org.
Moblin and Maemo to merge Posted Feb 16, 2010 18:12 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
that doesn't match up with the articles that have appeared here about the development of rpm.
Moblin and Maemo to merge Posted Feb 16, 2010 18:22 UTC (Tue) by skvidal (subscriber, #3094) [Link]
It matches up to reality.
rpm.org is the branch being used in all the major distributions.
Moblin and Maemo to merge Posted Feb 16, 2010 23:02 UTC (Tue) by foom (subscriber, #14868) [Link]
Maybe you confused rpm.org with rpm5.org (How anyone could ever make that mistake I don't
know! :P)
Moblin and Maemo to merge Posted Feb 17, 2010 0:37 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
since I don't use a rpm based distro, it is fairly easy to get confused, but just the fact that there is both the rpm.org and rpm5.org would seem to mean that there are different versions of rpm floating around.
Moblin and Maemo to merge Posted Feb 17, 2010 5:43 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
There are fringe forks of everything that you can think of but what matters
is what is getting used by many people and that boils down to what the major distributions ship which is the same branch
Moblin and Maemo to merge Posted Feb 15, 2010 20:20 UTC (Mon) by Janne (guest, #40891) [Link]
"oh when I say deb i mean apt-get/aptitude/deb as a whole."
OK, please then point your criticism at the right target, as opposed to blaming the packaging-
"I had pretty bad user experience with rpm(dependency hell,etc), as simple as that. With deb so
I have had similar experiences. Back when I used SUSE (IIRC), I ran in to cases where I had to
Needless to say, when rpm-based distros got better tools and repositories, they became just as
Moblin and Maemo to merge Posted Feb 15, 2010 21:47 UTC (Mon) by GhePeU (subscriber, #56133) [Link]
Are they really trying to kill Linux on mobile devices? Nokia should never have bought TrollTech if this is the result.
First Maemo, now Moblin, this is the second time a promising project is going to waste months rewriting everything because Nokia decided to shove QT in it.
Maemo already had three releases, Moblin had a fantastic interface, a new release coming out in a couple months and they just dump it in the garbage pile. What is Intel thinking? It's not like there are thousands of QT applications out there or developers waiting to target a new platform, especially a platform which could easily change again (it did it twice already).
All of this when the time window for introducing a new product without having to fight with already established incumbents is becoming smaller.
Moblin and Maemo to merge Posted Feb 15, 2010 23:09 UTC (Mon) by xxiao (subscriber, #9631) [Link]
I think it's their response to android, as moblin/maemo have relatively small communities and less active development, comparing to what happens with android these days. Competition is a good thing, though.
Moblin and Maemo to merge Posted Feb 16, 2010 9:51 UTC (Tue) by boudewijn (subscriber, #14185) [Link] Well, there are thousands of Qt applications and hordes of Qt developers out there, you know.
|
|||||||||||||