Red HatThis forum is for the discussion of Red Hat Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Does anyone know of any Official tools like Synaptic+apt (www.freshrpms.net) that RedHat might be working on to include in future releases? I know that would probably take care of over half of the issues newbies have when converting over or selecting an OS that's both as easy to use as it is Secure.
Any info on this, maybe even a link or 2 to official (or well accepted) sources would be great!
Probably you have heard already that up2date will support Yum/APT repositories.
Red Hat's own redhat-config-packages utility is still work-in-progress, too. It will need at least a way to access RHN (like up2date) in order to be really useful. Currently, it fails as soon as you try to add development packages to an up-to-date system.
You could also search SourceForge.net or Freshmeat.net for package tools like RPM Wizard: http://rpmwiz.sourceforge.net/
I was hoping more to hear that an actual tool for resolving dependencies (not quite like up2date..) in general would actually be supported and come default, it's quite the thing to see literally over 50 threads a day on problems with dependency issues, which can easily be resolved by including Synaptic+apt, or creating a tool that is very similar to (clone) that combo.
Mandrake has it with urpmi
Debian has it with apt-get
Gentoo with Portage/emerge
Arch with pacman...
So I was just hoping RedHat could set the standard as they usually do and make their own that takes all of those (and others) into account, build something that resembles them, but has all the pluses without the bugs/minuses, and include it in a near future release. I know that'd be a huge "selling point" for the distro, and Linux as a whole (as RedHat really represents Linux in the eyes of those who learn about it, especially corp..)
Distribution: Fedora Core 2, SuSE 9.1 Professional
Posts: 189
Rep:
I think that Red Hat has a partnership with Ximian and Red Carpet. If you don't have Red Carpte, you might try it...it's free in it's basic form. It will only work with subcribed channels (most of them free) but if you ever need to install anything it solves the dependencies by acquiring the software and configuring the "transaction" as they call it.
This might be the direction they are going. However, I hope that they develop it or make their own tool LIKE it that can get ANY software and make it work, solving those issues. This is one of the MAJOR hold-back items for a lot of people using Linux. They are on the right track, but there is a ways to go
So I was just hoping RedHat could set the standard as they usually do and make their own that takes all of those (and others) into account, build something that resembles them, but has all the pluses without the bugs/minuses, and include it in a near future release. I know that'd be a huge "selling point" for the distro, and Linux as a whole (as RedHat really represents Linux in the eyes of those who learn about it, especially corp..)
A package utility is useless without fully compatible packages/repositories. The main problem is not the package utility that solves dependencies, but to keep newbies away from incompatible packages. Installation of packages is not like executing an EXE file. A Red Hat Linux user who tries to install binary packages made for Mandrake Linux is likely to be disappointed when the package tool doesn't help. By including Yum into the distribution and supporting APT/Yum repositories with up2date, a first step towards supporting external package source is achieved. Maybe more software vendors will then offer RPM packages rather than creating custom tarball/shar-based packages.
I understand that it's a bit more complicated than exe install, behind the curtain that is. However, to the user, what happens with their interface doesn't really have to be much more than a few clicks (such as an exe). The already available tools coupled with a bit of shaving and tweaking could easily give the feel of "exe" handling. Here's the scenario:
A user finds an application they want to install, for ease let's say Mplayer. So they open up their "installer" and type:
mplayer
It pops up a few version choices, the user selects the version they want, and click next. In the next screen is a list of repositories/servers to choose from. Listed by Country/State and city, so the user can pick the one closest to them. They check the box, and click next. In the next screen it asks which desktop env they are using, they select from a drop down list, if the one they are using does not exist, the options for "menu placement/desktop icon" gets blurred out (thats check boxes below the drop down), and they click next, the "changes" are shown, and they click finish. The package is downloaded along with it's dependencies from the mirror they selected, and finally installed, and a "Complete" dialogue box pops up telling them it's finished.
It really wouldn't be all that much work since most of these things exist already, they simply need to be sanctioned by RedHat, included in new releases, ported to old ones, and have stable repositories (which already exist via "mirror") to keep the files in. In the unlikely event (if RedHat actually did something like this, I'm sure that Vendors would put out significantly more RPM's, etc) that something wasn't available on ANY repository, it would switch to source, download and compile using a standard set of instructions (which are determined during install anyway) for the processor, and using something similar to checkinstall, create an RPM and install via the already existing RPM tool (for the database), ala Gentoo.
This is what I mean by using all the tools already available, and putting them to use as a unified tool, sanctioned by RedHat, included in all future releases AND back ported to older ones (say through 7.x). It would catch on like it's sliced bread, as mentioned Mandrake, SuSE, and anyone else could easily also benefit from the same tools/repositories, so there goes the non-standard -mdk rpm's... It'd be a better place.
RedHat could do it, and they'd be the ones to lead as they have so many times in the past. They could even include the other main contendors in on the development to make sure everyone is/was on the same page.
Really, combining:
Synaptic, Portage(emerge), up2date, urpmi, and apt into a single tool bred for ALL distros would NOT be that hard, not for someone/something like RedHat.
Please feel free to shoot holes in anything I've said, I'm hoping for more discussion, from anyone on this!
It would catch on like it's sliced bread, as mentioned Mandrake, SuSE, and anyone else could easily also benefit from the same tools/repositories, so there goes the non-standard -mdk rpm's... It'd be a better place.
I don't understand this. MandrakeSoft use RPM, SuSE use RPM. Still they use RPM differently. They define their own macros. They choose some package names that differ from the rest. They package software versions which are ABI-incompatible with other Linux distributions. I don't see how a new mighty package tool would change that.
Quote:
Really, combining:
Synaptic, Portage(emerge), up2date, urpmi, and apt into a single tool bred for ALL distros would NOT be that hard, not for someone/something like RedHat.
Each vendor would still implement support for their own specific errata repositories, e.g. Red Hat [Enterprise] Network.
Also, I don't understand what the benefit of "combining" existing tools would be. Any new front-end to RPM could do. As outlined before, up2date, for instance, will support apt/yum repositories in addition to Red Hat Network and local folders. And if memory serves correctly, some package tool developers work on standardizing package meta information, so e.g. apt/yum would not require different types of repositories.
Once more, the difficulties are not in creating a unique package format or package tool. The difficulties are in providing software that works on and is supported on all or the majority of Linux distributions. As long as a user of Debian GNU/Linux has access to prebuilt packages not available to a user of SuSE Linux and vice versa, we're quite a step away from EXE-like software installation.
The Krud distro is based on RH9 and delivered in a 3 CD set via snail mail monthly. Synaptic is installed as standard and can be used between CD updates.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.