Recent Features
| |||||||||||||
A possible change of direction for Foresight LinuxA possible change of direction for Foresight LinuxPosted Aug 15, 2009 18:11 UTC (Sat) by drag (subscriber, #31333)In reply to: A possible change of direction for Foresight Linux by AlexHudson Parent article: A possible change of direction for Foresight Linux
> If there's value in doing it, I would say there is more value doing it as a Fedora spin/remix: using the native package manager has to be better, and where Foresight creates value that can be fed back into Fedora.
I don't see any reason why it 'has' to be better. RPM is just a archive format with package-management metadata added on. It's not really substantially different from a Slackware tarball or a Debian deb format. Same concept, similar information, just different format.
The biggest hurdles for users are silly things like differences (as long as your dealing with distros from same eras) in what versioning numbers are and details on how larger projects are divided up into smaller packages.
If RPM can be converted to using Conary then I don't see any reason at all why they shouldn't just take Fedora's binary's and use them for themselves. Maybe this sort of thing will help convince people that 'compile everything from scratch for each distro' isn't really necessary. I mean everybody is using the same compiler, same kernel, same userland source code for everything already. It's not like anybody is trying to build systems with PCC or Intel's c compiler or anying bizzare like that.
Personally I'd like them to use Debian's stuff. But Fedora has caught up in a lot of ways in terms of consistency and quality of packages.
And, after all, rPath and Conary were designed/founded by ex-Redhat employees using lessons learned from developing RPM.
RPM and the related package management tools were designed to be used through CDs and individual FTP downloads.. they were never originally intended to be like 'apt-get'. And sure you have 'yum' now and advanced tools, but they are still years behind the quality, capabilities, and speed that Debian's system offers.
Conary, on the other hand, was designed specifically for Internet distribution from the ground up and has a lot of advanced concepts that even Debian can't match.
The biggest concept is that its effectively a revision control system for your OS. It does not track things by package lists, it tracks each individual file. So theoretically it won't matter what sort of package you use as long as Conary understand the format... if you have conflicts and overwrite files from different packages then Conary, theoretically, should be able to handle that in a graceful manner.
If you ever tried to back out of a broken Debian upgrade or a botched Yum update then you know that it can be a painful process and can take several hours of work and mucking around with a broken system before you can get it working again. Doing a serious upgrade from something like Debian Stable to Debian Testing is pretty much a irreversible choice for most people. Sure it's possible to downgrade, but the tools were never intended to deal with that effective.
With Conary that sort of thing is designed into it. It's intentionally designed for effective rollbacks and whatnot.
(Log in to post comments)
A possible change of direction for Foresight Linux Posted Aug 15, 2009 18:26 UTC (Sat) by AlexHudson (subscriber, #41828) [Link]
Given that they're using RPM packages, I find it difficult to see how conary could better manage that information: sure, it does the "revision system" thing, but RPMs contains scripts and other stuff that make them a bit more complicated than that.
I'm sure that using conary would mean you could do things like roll back updates and stuff, but I'm equally sure that the impedance mis-match between rpm and conary would cause other stuff to screw up.
For the sake of a slightly different package management system, it seems like an awful lot of effort when the easier path is just to base on Fedora.
A possible change of direction for Foresight Linux Posted Aug 15, 2009 18:45 UTC (Sat) by drag (subscriber, #31333) [Link]
From the article:
> Most of you know that rPath now provides multiple OS bases by importing existing OSes built with other technology into a Conary repository. We have automatically-updated imports of SLES 10 and SLES 11 (both available by subscription only), CentOS 5, and Scientific Linux 5. We have imported a version of Ubuntu Hardy as a functional proof of concept that we can improve based on customer demand. We have done some work on importing a few other OS variants, too. We do this with a tool that we can make available as Open Source so that Foresight is not dependent on rPath to maintain the import of another more frequently-updated OS as a base.
It seems they already know how to overcome the hurdles for paying customers.
rPath, as you are probably aware, is a decently successful company that specializes it producing "linux appliances' for lots of different sorts of customers. They do this by taking a base OS and introducing it into a revision control system so that they can tailor it to the specifications and release it as a 'vmware player' guest and other such things.
Been around for a while now.
A possible change of direction for Foresight Linux Posted Aug 15, 2009 19:11 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
I would note that capabilities of RPM based systems in some ways have been better. For specifics consider
* Gpg verification, IIRC in RPM based systems first
The catching up goes both ways.
A possible change of direction for Foresight Linux Posted Aug 15, 2009 19:17 UTC (Sat) by drag (subscriber, #31333) [Link]
Ya I thought so to. RPM is probably a better/more sophisticated format then Deb.
But Debian's tools for managing packages are more mature in my experience.
A possible change of direction for Foresight Linux Posted Aug 16, 2009 1:58 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Debian dependency management is still better. DEBs can have hard, suggested, optional and 'conflict' dependencies. RPM still has not caught up with that.
A possible change of direction for Foresight Linux Posted Aug 16, 2009 5:22 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
That's incorrect. SUSE, Mandriva and others have been using those for years now and RPM has file based dependencies as well. Apt would do nothing but print the "suggested" dependencies. I haven't checked whether that is the case still.
A possible change of direction for Foresight Linux Posted Aug 16, 2009 9:50 UTC (Sun) by Frej (subscriber, #4165) [Link]
And what's the point of suggested/optional dependencies?
It's not like any user actually knows - it's never explained. They are just 'optional' or 'suggested' - that doesn't help the user in me ;). (or anyone else but the packager).
If it's some library enable a feature in an app.
Like automatic codec installation ;).
A possible change of direction for Foresight Linux Posted Aug 16, 2009 14:56 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
Several uses:
1. Allowing a package to "depend" on packages not in the repository.
Package management tools tend (e.g.: usually default to-) install "Recommend" type of dependency by default unless it causes a conflict or some other problem.
A possible change of direction for Foresight Linux Posted Aug 17, 2009 0:28 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
For example, JDK suggests X libraries (for Swing and AWT), but can be installed without them (it's a suggested dependency). Or a daemon might suggest a GUI front-end, but can work without it.
Another example, several packages suggest Avahi as a dependency which makes a perfect sense for desktop users (i.e. you probably want to install Avahi if you install NetworkManager), but makes little sense on the server (I _do_ _not_ want Avahi if I install lib32nss).
So in practice, DEB-based distributions are nicer to work then RPM-based ones. Though RPM is getting somewhat better, a few years ago most RPM distributions were a junkyard of broken packages.
A possible change of direction for Foresight Linux Posted Aug 17, 2009 15:51 UTC (Mon) by vonbrand (subscriber, #4458) [Link] This is exactly the wrong way around: The GUI requires the daemon, not the other way. Besides, what use is a bare "suggestion" to a plain user? If they know their way around the system, they'll know what they need (or can live without), if they don't, they will have to find out somehow.
The slur that "most RPM distributions were a junkyard of broken packages" was never true. What happened is that there are lots of RPM-based distributions around, and thus all sort of people tried to force-install packages from one on the other, with the obvious ensuing breakage. What saved
A possible change of direction for Foresight Linux Posted Aug 17, 2009 16:07 UTC (Mon) by martinfick (subscriber, #4455) [Link]
"This is exactly the wrong way around: The GUI requires the daemon, not the other way."
I find it very helpful when I install a package to have apt suggest packages that might be useful along with a package I am installing. It is a huge advantage to not have to always research things, but to simply be able to say, sure, "I'll try that too"; or "no thanks", I don't need support for "ldap, X...". It is not a dependency, just a suggestion.
And not all GUIs require their daemon anyway, the daemon might be running on some other host(s).
Clarifying context of comparison Posted Aug 15, 2009 20:51 UTC (Sat) by michaelkjohnson (subscriber, #41438) [Link]
I think you are comparing RPM to dbkg rather than RPM to Conary, correct?
Just to be clear for all the readers here, Conary has had all the features you list since near the beginning of the development process (rather than delta RPM, it's native format is a changeset which is normally relative; a reliable analog of delta RPM). There are some specific ways that the way Conary supports some of those features is better than RPM, and I'd be happy to discuss them, but it's somewhat out of scope for this thread.
To be clear; RPM existed before Conary -- given that Erik Troan was the principal author first of RPM and then of Conary based on his RPM experience, that would obviously be the case...
Clarifying context of comparison Posted Aug 15, 2009 21:05 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
Yes, I was comparing the format rather than the tools around that.
A possible change of direction for Foresight Linux Posted Aug 16, 2009 12:22 UTC (Sun) by juliank (subscriber, #45896) [Link]
Debian packages have a much simpler design than RPM. This makes it easy to unpack them even without having dpkg installed, as it is just an AR archive with two tarballs.
Now, some of my thoughts on your comment, from my Debian PoV:
> * Gpg verification, IIRC in RPM based systems first
> * Multi-lib support (next Debian release goal)
> * Automatic debug info generation (next Debian release goal)
> * Delta RPM integration
> * Separate patches
> * File capability support?
A possible change of direction for Foresight Linux Posted Aug 16, 2009 16:43 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Multilib - Fedora has not installed both arch packages by default in a x86_64 system for quite sometime now although there is a simple setting to change if you prefer it.
DebDelta is not integrated into the distribution like DeltaRPM in SUSE and Fedora after that.
Separate patches - RPM has always used granular patches unlike Deb where usually many of the patches are put up into a single archive. This makes it harder to cherry pick some of them. I know this isn't always the case.
File Capability - Writing a script is fragile. Fedora is going to use this RPM capability by default in the next release
https://fedoraproject.org/wiki/Releases/12/FeatureList
If you want more, Fedora is also using XZ compression by default in the next release as well. My point is simply that catching up is bound to happen on both sides.
A possible change of direction for Foresight Linux Posted Aug 17, 2009 15:33 UTC (Mon) by vonbrand (subscriber, #4458) [Link] If RPM can be converted to using Conary then I don't see any reason at all why they shouldn't just take Fedora's binary's and use them for themselves.If they are so compatible, why "convert" at all? Maybe this sort of thing will help convince people that 'compile everything from scratch for each distro' isn't really necessary. I mean everybody is using the same compiler, same kernel, same userland source code for everything already. It's not like anybody is trying to build systems with PCC or Intel's c compiler or anying bizzare like that. This is dead wrong. There are differences in exact versions (particularly when packaging upstreams that don't release that often, where you end up taking some kind of semi-random snapshot plus suggested fixes), configuration (not all distributions use vanilla configurations; some include support for stuff important to them, others delete something they can't include for whatever reason), where exactly configuration files are stored (yes, this is in the binaries), what compiler flags are used, exactly what versions of the used support libraries are shipped, what (extraofficial or local) patches are added, and a host of other differences. The source differences are (thankfully!) shrinking as distributions figure out that it is better to do bug fixing and enhancing (with) upstream, but they haven't dissapeared.
|
|||||||||||||