| |||||||||||||
A possible change of direction for Foresight LinuxA possible change of direction for Foresight LinuxPosted Aug 15, 2009 19:11 UTC (Sat) by rahulsundaram (subscriber, #21946)In reply to: A possible change of direction for Foresight Linux by drag Parent article: A possible change of direction for Foresight Linux
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.
(Log in to post comments)
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.
|
|||||||||||||