Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Ximian

Ximian's Red Carpet Released 152

Posted by Hemos from the expected-but-cool dept.
assbarn writes "Ximian has announced that they have released Red Carpet, their new updater application and software management tool. This marks a huge improvement over their old updater service, with full dependencies (a la apt) for both RPM and dpkg systems, and a channel system that can provide any kind of software to your Linux system." I've included their release below - check it out for more information.

Red Carpet Release Info, from Ximian

You have waited frothingly in anticipation. You have endured a perpetual release date of "two more weeks." You may have, in a senseless act of anxiety over this amazing work of art, even whispered the "V"-word[1] under your breath. You have tormented the developers on IRC. You have begun the chanting. You have burned towns. You have seized ships and blockaded ports.

Red Carpet is here.

Red Carpet is the next generation Ximian updater and software management application. Based around the concept of "channels," or content groupings, Red Carpet will be able to present you with a virtually endless array of software for your GNU/Linux and Unix systems. In addition to just updating packages already installed on your system, Red Carpet allows you to install new software and remove existing software. Red Carpet operates seamlessly with your existing packaging tools on both RPM and dpkg-based systems, giving you a consistent interface for managing your software on any Linux distribution. And, with DepTricketyTrackTrackTronixTron 9000, our amazing dependency and conflict resolution system, the nightmare of dependencies all but vanish from your life. Rejoice.

We will now move into the question and answer section of our release announcement:

Q. Is this a beta? 0.9? What's going on here? Where am I? Why am I wearing a clown wig?
A. With our best efforts we have tried to find every bug, duplicate every dependency situation, become one with both RPM and dpkg, and click on everything rapidly and repeatedly. However, we are most ashamed to admit that we did not discover every possible bug, could not duplicate all of the horrors that are your packaging database, failed to achieve spiritual enlightenment, and simply cannot click as fast as you can. As a result, we present this application to you in beta form. Frankly, we want you to do thangs to it. You find bugs, we'll fix em.

Q. How do I get it?
A. Binary packages for Red Hat 6, Red Hat 7, and Debian GNU/Linux systems are available now through the Red Carpet mirror in the Ximian GNOME Updater. For Debian users, add this line to your /etc/apt/sources.list: deb ftp://spidermonkey.ximian.com/pub/red-carpet/binary/debian-22-i386/ ./ You can also get them, as well as the source tarball, from ftp://ftp.ximian.com/pub/red-carpet. Because we're in the process of moving our office and we overwork our build people, binary RPMs for the remainder of our supported Linux distributions will be available a little later. Sorry.

Q. Okay, I've got it. Now what?
A. Give it a whirl. You can find Red Carpet from the Programs->System menu on the foot launcher or on the top menu bar. After it downloads all of the channel bar, you should probably verify that your system's dependencies are fulfilled by choosing "Verify Installed Packages" from the File menu. After that, go buck wild. Subscribe to channels, install new software, check out our totally l33t About page, whatever you want.

Q. "I found a bug" or "Red Carpet sucks! How do I tell you how bad you suck?"
A. In the unlikely event that you find a bug, please submit them to the Ximian bugzilla at http://bugzilla.ximian.com. We've created a public mailing list, red-carpet@ximian.com, for you to tell us exactly how much we suck. Or rule. We're ready for it. We can take it. You can subscribe to it at http://lists.ximian.com/mailman/listinfo/red-carpet. By the way, help control the pet population: have your pets spayed or neutered.

Q. Tell me more about channels.
A. That's not really a question, but I would be happy to. With channels we are able to provide you with a much wider variety of software and in a much cleaner way than what was possible with our old updater technology. Channels can be subscribed to selectively, meaning that you only ever receive information on updates of software that interest you.

Q. So, uh, does that mean it'll update my distribution, too?
A. Oh yeah. Red Carpet detects what distribution you are running and presents a channel of it, with all of the updates issed from the vendor. Red Carpet can install any software on your system, as long as there's a channel for it. In essence, Red Carpet becomes the central point for installing, updating, and managing software on your computer. Q. What about package signing and verification? A. You'll want to install GnuPG to verify package signatures. We have included the public keys for Ximian, Red Hat, Caldera, TurboLinux, Mandrake, and SuSE. Most distros provide them these days. If you don't have it, Red Carpet will still run fine.

Q. Does this replace the Ximian GNOME Updater?
A. Because this is a beta, we don't want to prevent people from updating their system in the event that it breaks. As Red Carpet is an infinite improvement over the old updater that we introduced in March 2000 in every way, it will replace the Ximian GNOME Updater at some point in the future. In the meantime, however, they should both work.

Q. You broke my Evolution snapshots. What the hell? A. Sorry bout that. It was necessary to eliminate a pointless dependency on Red Carpet. Your Evolution will be broken until you install new snapshots (which should be built tonight). Look on the bright side, though, you'll be able to install those snapshots with Red Carpet! Sweet!

Q. Who worked on Red Carpet?
A. Red Carpet is the result of months of work by the following people:

DEVELOPERS:
Ian Peters
Joe Shaw
Vladimir Vukicevic

CONTRIBUTORS:
Jacob Berkman

USER INTERFACE DESIGN:
Anna Dirks

ARTWORK:
Tuomas Kousmannen
Jakub Steiner

In addition, many thanks go out to Larry Ewing and Radek Doulik for their work on GtkHTML, on which Red Carpet heavily relies. They've had to deal with our constant pestering in addition to those of the pesky Evolution developers. All too often our conversations went like this:

"Dude, there is a bug in GtkHTML."
"That isn't a GtkHTML bug."
"Yeah dude, it is.
"Dude, no it isn't."
"Dude, it is."
"No, dude, it isn't."
Pause.
"Hmm. You're right, it isn't. Sorry, dude."
Thanks, guys. We're dorks.

Lastly, special thanks go out to Matt Wilson, who, aside from his help, plain and simply totally rules.

Q. How many inside jokes are in this release announcement?
A. I quit counting around eight. Joe Shaw, however, will give one hundred AMERICAN dollars to the first person to identify all of them and their origins.

[1] Vapo(u)rware.

This discussion has been archived. No new comments can be posted.

Ximian's Red Carpet Released More

Ximian's Red Carpet Released

Comments Filter:
  • What I think he means is; stuff from the base-system (like telnetd, inetd etc.) cannot be upgraded using the ports-system. But that's not
    what the ports-system is about. If you want to upgrade/patch stuff from the base-system, you can easily do that via cvs. Just checkout the new version of telnetd, and compile and install it.
  • Thanka for making the point - I didn't have the time time to illustrate the full sequence.

    But APT isn't Debian or .Deb specific. You could install Conectiva or the Mandrake 8 beta, both of which are APT based RPM distributions.

  • I know that - but that isn't what the error message says, which was what I was originally posting about. The original message implied (to me anyway) that it wouldn't install that package because of the package version (i.e. the software within it). It's a crappy error message.

    Anyway - firmly off the beaten track now.
  • Read the press release and the web page moron.

    It specifically mentions this, you have an inconsistent RPM database, so some dependancies could be stuffed.
  • All you people complaining about minor updates requiring the removal of great swathes of your systems, did you even read the press release and the posts on news.gnome.org from the developers, and the red carpet web site.

    This is a known problem, not with Red Carpet but with your package databases (specially the RPM one), thats why they tell you to verify installed dependacies before you do anything else.

    once I got rid of the problems in my rpm db (double installs of auth_ldap and kdesupport, which RC detected and told me there were problems with), RC worked perfectly, cept for some issues of crashing when installing the RPMS but that was a gal issue.
  • Hey what ever happened to those goat pictures? we got em still on soul, right? :)

    Mike Roberto
    - GAIM: MicroBerto
  • Ummm, call HP and ask to purchase their Visualize Linux workstations. :) It was a very smart move on their part - it's easily the most stable X/OpenGL that I have personally run on Linux. Definitely faster than XFree and more powerful in the OpenGL dept. Obviously ported from their HPUX.
    It runs *instead* of XFree, and we use these workstations to make money, so if some update app refuses to work unles we use XFree(which apparently isn't the case - thank's Joe!), then we can't use it. The HP Visualize stations start with a standard Redhat install, then install their X over top. Believe me, when you're in the high end - all the "cool" stuff XFree provides is meaningless when you're looking for serious OpenGL performance. The Mesa guys are the first to admit that - it's not in that league yet.

  • Red Carpet is not a complete platform installation updater, but rather only for one version of the GUIs supported. M$, inspite of my intense dislike for them, deserves credit here: their updater updates most of the platform in one updater: quite slick and very time- and error-saving. Now if it just compiled from source each time ;-) When is the Linux vendor community going to quit their package wars and band together to help make Linux easier to install. HINT: start with XFree86!
  • Somebody's got to pay the Akamai bills. None of us can afford to do it alone!
    On the other claw, Ximian could use Skycache/Sidera for their web caching, since they use linux & netbsd instead of the proprietary code that Akamai is built around... I don't know what the billing & performance differences are.
    --Charlie

  • Your criticism is interesting, but unfounded. The FreeBSD ports system does maintain version information in the package database, represented in the filesystem as the /var/db/pkg heirarchy. Also, you can query the package versions through the "pkg_version" command. There's also a way to use the pkg_version command to automatically update any ports that are out of date, or to list all the installed packages.

    Since each installed port has an entry in the packages database, ALL the package management tools work well with ports. For example, you can use pkg_delete to cleanly uninstall a port in a way which will track dependencies.

    To be honest, I tend to access the raw filesystem directly more often than I use the various pkg_* commands. For example, seeing what version of qmail I have installed is as simple as "ls -d /var/db/pkg/qmail*",

  • Nice piece of work here. It looks like you've really put yourselves into this one, and from the missive above you either had a bunch of fun writing it or your marketing people are not your average bunch of monkeys.

    My one concern with all these kinds of systems is infrastructure. For one, I can remember when getting an RPM from redhat.com was a pain because they didn't have their mirror's set up and their ftp site was getting hammered all the time, but I'm not really concerned about scalabilty bottleknecks, that's really just relationship building and it sounds like you have a lot of friends. ;) What I'm more concerned about is "channel" maintenance and what the chain is for that?

    Does channel == ftp server?
    Who maintains that channel?
    What would be a reasonable timeframe to expect an update to a channel in the case of say, the bind security problem from a few weeks back?

    Too often it seems to me that the web of trust between me as a sys admin and package maintainer x is not as stable as a simple `gpg --verify`. I realize that your updater is probably not geared towards me, but I need to understand the system which I am utilizing before I could consider adding your monkeys to my arsenal.

  • Yeah ok but what about the other stuff on www.ximian.com? Like gnome etc..?
  • pkg_version -v ouputs something like this (and a whole lot more of this):

    screen-3.9.8_3 needs updating (index has 3.9.8_5)
    sox-12.16 needs updating (index has 12.17.1)
    tcl-8.3.1 * multiple versions (index has 8.0.5,8.2.3,8.3.1)
    tiff-3.5.5 = up-to-date with index

    As you can see this says enough about versions, and it also tells you what needs an update, and what doesn't...
  • Er, I have automatic updates. I have dependency tracking. I have channels too - in fact, I update my Helix Gnome regularly using them. It's called apt/dpkg, and it's a standard part of Debian.

    Now, a GUI tool for setting up and administering APT could be very cool - I'm not making a CLI vs GUI argument here - but why might I want another system to do basically the same job bolted onto the side? If there are things that Red Carpet does that apt/dpkg doesn't, wouldn't it be best to fix apt/dpkg?

    The Helix people know Debian, so I'm sure they've anticipated this question, but I'm surprised not to see it answered here.
    --

  • Simple question (Score:4)

    by Matthias Saou ( 264938 ) on Wednesday February 21, 2001 @03:02AM (#414958) Homepage

    Red Carpet seems quite interesting... as soon as the Ximian ftp lets me in or if I find a mirror that already has it, I'll try it :-)

    I have one simple question though :
    This "updater" will update all the Ximian Gnome part of the system (to replace the Helix updater) but also the core of the distribution (Debian users won't be much affected, but RedHat users like me will)... but can it manage other groups of packages???

    I'm asking this because I maintain many useful custom RedHat 7 RPMs people really seem to like available from http://redhat.aldil.org/ [aldil.org] and it would be great if I could (and others that trust me too of course) put my public GPG key into my Red Carpet and manage all my custom RPMs from it. I'm ready to make xml files describing my packages on my server (if that's how it works) etc. to get things working.

    Does anyone know if this would/will be possible? I would be soooo pleased if it was :-)

  • That's what I meant. But if I upgrade the base-system using CVS, doesn't this mean, for example, that old files are left lying around, configuration files will be over-written or not upgraded, etc? And that you can't later ask the system, "where exactly did THIS file come from?"
  • Damn thats an unclear error message then - surely it should read:

    only packages with RPM file format version <= 3.x are supported by this version of RPM

    or similar? I was looking at the error and thinking but it's 0.something! that's <= 3...
  • Nope. You can use 'Mergemaster' for that.
    (Simply merge any changes)

    Check the FreeBSD handbook on updating your
    system...

    http://www.freebsd.org/handbook
  • If you think it's not important, why haven't you disabled Ximian-postings in you prefs?

    Change 'em, then complain...

    kenneth

  • It is beta software. One thing it does is try to update your kernel in RH7, badly. Auto kernel updates are a bad idea, but other than that it does have promise.
  • ...is a superior OS to linux
  • woweeee! this is some inane shit!
  • logan@xxxx:~$ cat /etc/slackware-version
    7.1.0
    logan@xxxx:~$ head /var/log/packages/sendmail
    PACKAGE NAME: sendmail
    COMPRESSED PACKAGE SIZE: 873 K
    UNCOMPRESSED PACKAGE SIZE: 2230 K
    PACKAGE LOCATION: ./sendmail.tgz
    PACKAGE DESCRIPTION:
    PACKAGE DESCRIPTION:
    PACKAGE DESCRIPTION:
    PACKAGE DESCRIPTION:
    PACKAGE DESCRIPTION:
    sendmail: sendmail 8.11.0.
  • But you still haven't answered the question about finding out what package a particular file belongs to.

    Is there a command to tell me if the package files are intact or not? Something like a pkg_verify?

    I used FreeBSD 4.0 for a while (1 month on a laptop) and while I like some things about the ports collection better, it also has its problems, they are just different. (Wow how is that for a run on sentence!).

    What I am trying to say is that every package system has its negatives and positives. I am sick of people saying the ports collection is the *best*, what they really should be saying is that the ports/packages collection is best for *them*.

    Note: If you want to rant about how I wasn't specific in the above paragraphs complain and I'll post some specifics.
  • Might be a bad idea to depend on a company with an equally crappy buisness plan. If you don't think it is a crappy plan, explain how they will ever make enough money to reach the point where they can do research in addition to development.
  • ... over zealous dependancy requirements? I get sick of downloading RPMs which refuse to install unless I have this morning's build of QT only to find they run fine when installed with --nodeps.

    TWW

  • In debian's aptitude program, you can hit ctrl+c on a package to see it's changelog
  • no, you can't with Ximian update it all... yet...
  • Umm.. it's not that they hate slack, but slack does not have much of a packaging system. At least not as sophisticated as apt/dpkg let alone rpm. Hence it makes their jobs harder. I doubt they'll get around it.
  • I refreshed and saw the text: 0 of 1 comment.
    I clicked on the "read more button".
    5 comments, 2 below your current threshhold.
    Bullcrap.
    Anyway, so that I'm not offtopic ;) I'll say something interesting.
    Why would we need YAPM (Yet Annother Package Manager)??
    At the moment there are RPM's, DEB's (apt) and they are cool enough.. then there's the good old tarballs, and BeOS PKGs', then there's QNX' package manager, and loads of time..
    Ok. Anyway.. nice work...
  • For those using ximian on a debian system know, updating packages can often bork your system because Debian wants you to download debian gnome and I want ximian gnome. Becuase of this, if I don't specify all of the ximian packages over the possible more recent debian packages, the system gets borked. Will RC make sure that it only installs ximian gnome packages, but still install standard debian packages?
  • I am actually thinking of setting this up after I looked through the website,
    does anyone have any expereience with it, and how hard it is to get running? Or is it just one RPM to download and it works?
  • This is a good tool, but it only hides the problem and doesn't solve it. So now you have one GUI and one tool to keep track of dependencies and get the packages, but you still need the rpm-tools, the deb/apt tools, you have both databases, you need perl for most debs and you need GNOME to use the tool.
  • All right, now I'm quite convinced. I'm still new to this BSD stuff so I'm happy this got all cleared.

  • Dependencies of course.

    For me: orbit dep liborbit0 (=0.5.3-helix1) but have 0.5.7-1

    __
  • The original tools (rpm and dpkg) or an own tool slurping both formats and building an own database in an own format? When it uses original tools, then there are two databases.
    It is definitely a step in the right direction, but to use this tool you need several MB of software installed to use it.
    It isn't graphical for debian by default. But there are graphical tools. dselect is a nuisance. But this makes it possible to make a Debian install with less than 30MB, as you don't need X and all this stuff. And if you not even use dselect (some fiddling necessary) you can have a Debian system of less than 10MB, as a file/mail server for example. Try that with any other general purpose distribution.
  • only packages with major numbers
    The key here is the word major.

    Most packages are numbered <MAJOR>.<MINOR>.<PATCH> or similar.



    Don Armstrong -".naidnE elttiL etah I"
  • What the hell.
    How come ximian doesn't support slackware?
  • OK then - count along with me:

    red-carpet-0.9-0_helix_1.i386.rpm

    major (0)
    minor (9)
    patch (0_helix_1)

    which part of 0 is greater than 3? Are we at cross-purposes here?
  • This piece of software is pretty good. It's currently installing a whole bunch of security updates for my RH6.2 installation, and it's been updating other things pretty well for now.

    A couple of days ago, KDE people told us that they're also planning on creating their own installer, but since this red carpet is so good, maybe they can become one of the channels on the red carpet installer.

  • Of all the Update programs I have seen, this looks the best. Anyone ever used WindowsUpdate? Its a great idea. Well thought out, too. Critical Updates, Reccommended Updates and Misc Updates that you might want just to have a new theme / look / sound.

    Red Carpet owes a lot to WindowsUpdate.

    Take a look. [ximian.com]


    There is one minor difference...

    Red Carpet is far less likely to fail installing updates, force you to reboot and corrupt vital system compoents. WindowsUpdate does that flawlessly.

    Overall, Red Carpet is far better than the Redhat Update script / wizard, and beats MandrakeUpdate hands down.

    IMHO, anyway.

    -----

  • Same here, the weird thing is that it wants to remove only my games and game libraries. I would understand if in the update list there were newer version of quake2, kingpin, or clanlib. But there isn't. Whats the deal? A feature that should be added is the ability to install with out removal. I can't upgrade to Gnome 1.4 using this tool with out removing the above items and everything else in the list. Jim
  • Has nothing to do with what's in the file name of the package, you could name that same package blah.rpm and it'd still throw back the same error.

    Update to a newer version of RPM. (You'll probably have to build from sources, of course...)
  • I updated Gnapster just fine without updating my kernel. It never said I had to do anything with the kernel to install it.
  • I've got KDE 2.1 beta 2 rpms installed on my box, downloaded from kde.org. RC wants to remove them and install 'official' kde 1.xx rpms from the redhat 6.2 site. And it does not offer me any option to leave those packages alone for a while, and just upgrade the packages that I selected.

    What it *should* do is allow me to leave the packages on the system, even if it thinks there are 'newer' or 'better' versions available. Debian allows you to "hold" packages at their current state (installed, not installed, whatever), and takes this hold value into account when calculating dependencies.
  • I had the exact same problem when I went to upgrade screen. Apparently the problem was that I had a duplicate install of Mesa (two different versions, I must have used --force). It probably picked a duplicate to uninstall, and wanted to take every dependency out with it. This happened to be KDE. This also happened with gkrellm -- multiple versions of the same package installed. I removed the duplicate packages manually, and everything worked fine after that.

    This is my fault, of course, for using --force and --nodeps which naturally can risk messing up your dependency database. I suspect a machine that uses strictly packages, properly installed (perhaps using Red Carpet from the start) will work great.

    One person who replied to you suggested that this was a big anti-KDE conspiracy from Ximian. Please, grow up, people (Macka).

    Jason.

  • I think (but am not sure) that GtkHTML is mostly for standalone applications that want to do slightly fancy things with text. I don't think it's suitable for web browsing at this point.

    Though I could be wrong, and often am.

  • Re:What does it do that Debian doesn't do already? (Score:4)

    by Eil ( 82413 ) on Wednesday February 21, 2001 @10:48AM (#414991) Homepage Journal

    The features of Red Carpet seem to be highlighted as thus: 1) Graphical interface 2) Easy to use 3) Works with all [popular] packaging systems.

    AFAIK, agt is only one of those. (#2 for those who couldn't guess...)
  • GOAT? they probably will, but mandrake has different packages and dependencies
  • I don't run into the same problem as you, I've got KDE2.1b2 rpms installed on an RH6.2 system, and RC doesn't say a thing about it. Did you --force any of the installs of the rpms? That's something that RC has trouble with, although I agree that "holding" packages back is definitely a feature worth adding to RC.

    Also, you do understand that this does not mean Ximian is trying to remove KDE from your system. This other guy thinks that Ximian is in some plot to remove all KDE rpms from people's systems.
  • Try gnome-apt. Yeah it's a little rough around the edges (OK a lot rough) but if you really need a graphical apt/dpkg tool it'll get the job done.

    apt-get install gnome-apt.

    I think kpackage in kde2 will also handle .debs properly, might want to try it out (if you want kde)
  • I downloaded it onto my RH7 system and went to the Ximian GNOME Desktop channel. It tells me there is one minor update (a newer version of gdm). Selecting gdm and clicking Update Packages, it tells me it needs to remove autorun, kdebase, kdegames, kdemultimedia, and kdeutils, in addition to needing gimp and kdelibs! Why does it want to remove half of KDE for gdm???
  • Doesn't some other linux company own the word "red" ?
  • We could use YAPM however. Deb is pretty good, but there still needs to be something better.
  • This allows your application to define a custom tag for the render to catch and call you - thus allowing your code to use HTML for displaying interfaces with complex parts drawn by custom GTK components. There are no security problems as they cannot be put on the Internet.

    For instance, consider a financial report with a movable, customizable graph inside it. Very difficult to do with standard HTML. Very easy to do when GtkHTML. As for security, the HTML is locally generated, and the embedded widget is from local code.

    Theoretically, you *could* use GtkHTML's abilities to do an ActiveX-like job, but that would be bad practice and no code using GtkHTML does it AFAIK.

  • You're only saying there's no package managing system because that's what people have told you. Fact is, there's utilities to install, upgrade, remove, and create your own packages. There are command-line utilities to do all of the above, as well as pkgtool if you want a dialog interface.

    These utilities have existed in Slackware since the beginning. Just because there's no dependancy tracking doesn't mean that there's no packaging system. Supporters of Slackware (me included) would tell you that the lack of dependancy tracking is a feature -- something best left to the system administrator to handle.

    So please, be a little more informed about your subject before you shoot your mouth off. It's perfectly reasonable to say: "There's no Slackware packages because their system requires dependancy tracking, and Slackware doesn't do that." It's not reasonable to say: "There's no packaging system to speak of." That's just completely untrue.
  • ximian must have cross licensed it
  • The same is true for RPM-based distributions: you get dependencies, automatic updates, channels, etc. The technical details are different and it's used less frequently with RPM but it's there if you want it.

    In my experience, none of the automatic upgrades are entirely reliable. Debian is so dependent on automatic upgrades that packaging bugs get fixed more frequently, but problems occur even with Debian and can be very annoying. I see little reason to upgrade continuously. If it isn't broken, don't fix it.

  • I'm behind a firewall at work. Those Red Carpet have support for a proxy server?

  • Where is this going? (Score:3)

    by q000921 ( 235076 ) on Wednesday February 21, 2001 @11:36AM (#415003)
    I believe both Ximian and RedHat are planning on making money off subscription upgrade services, and that looks a little like the fox guarding the hen house to me. If the people responsible for creating a lot of the software distributions and infrastructure also sell the subscription necessary to deal with that stuff, what incentive is there to make future distributions and package management simpler and more reliable?

    While I'm not saying it will go that far, the logical end point of this might be that you go to a web site, type in the bits and pieces of stuff you want, and have your raw disk image updated regularly. User-visible client-side package management would become irrelvant, you'd be completely dependent on the subscription, and you could forget about CD-ROMs or other disconnected installations.

    Yes, some form of convenient download and dependency checking is needed. And both RedHat and Ximian probably have the best intentions. But I'm not convinced that this is the right overall route to go in the long run.

  • Citing Windows 2000 as an example of an OS with built-in package management is highly misleading. Windows 2000 is just barely a year old and was the first Windows to have anything approximating package management. Their implementation appears to be quite poor. I've heard promises of DLL hell being a thing of the past, but I've seen several Win2K boxes go down in flames running only MS software and maintained by people highly proficient with Windows. (For example on a clean install, VB6 ate SQL7's lunch.)

    No, RH and Debian were the first consumer oriented OS's with Package Management (I forget, did BeOS too?).

    And what the heck does "bolt-on" mean? On a Linux box, everything is bolt-on except the kernel. A better word is "modular".
    ---
  • Very nice, but not for production yet. First thing it wanted when I tried to upgrade minor package on RedHat is to remove all KDE and Mesa installation altogether, without explaining reasons, and there were no way to make it to download that package (which has no relation neither to KDE not to Mesa - it was bind-util) and install it without blowing out half of my system.
    So, I know it's beta and it's expected - but don't try it to manage your production sites yet, or you'll be sorry. I hope they'll fix all the things, since the tool is looking very nice and promising and as soon as they will exorcize all devils from all the small things that would be the killer tool.


  • This clashes quite nicely with Eazel's Nautilus Software Catalogue. To quote their page:

    Take the frustration out of downloading and installing software! Eazel Software Catalog is a collection of popular applications and other software. Use Nautilus and the integrated Eazel Installer to download and install software in a single click.

    So which one of the two options are the distributions like Redhat going to promote? Or will they add a third choice?

    Macka

  • The only reason I am itching to get back into Linux is this
    For a windows user - linux install and shit floating everywhere - PAIN IN THE ASS
    also

    Dude, there is a bug in GtkHTML."
    "That isn't a GtkHTML bug."
    "Yeah dude, it is.
    "Dude, no it isn't."
    "Dude, it is."
    "No, dude, it isn't."
    Pause.
    "Hmm. You're right, it isn't. Sorry, dude."

    that is fucking funny
  • ... over zealous dependancy requirements? I get sick of downloading RPMs which refuse to install unless I have this morning's build of QT only to find they run fine when installed with --nodeps.

    Haha! I just grabbed the Red Carpet sources because of lack of native RPMS for my system, for now and I thought I'd better go 100% native with this kind of software. Now I've had a few RPM updates and source RPMS built to satisfy dependencies and I still haven't got this miraculous tool compiled yet! I certainly hope this is my last lib.so hell. Expectations UP, reality DOWN! :)

  • While I hated Aduva, I like this a lot. It still doesn't update my kernal correctly, but I've mostly stopped trying to update kernal rpm's through package management - it just doesn't work. The main thing that's interesting to me is how they have stated that they will use it to integrate with HPUX and Solaris 8. If I could have one package manager GUI (and I am assuming there is a CLI in there somewhere) to handle all my Linux servers, HPUX machines and Solaris machines... well that would just simply rule. Package managemnt on HPUX and Solaris is a real bitch.
  • I espected Red Carpet to be more integrated with apt-get. As it stands now I can access the Debian database but I can not access the additional sources in my sources.list.

    According to the Red Carpet homepage [ximian.com]:

    If you're an ISV or other software developer, and would like to have your software deployed with a Red Carpet channel, please visit our partners [ximian.com] page and let us know.

    Following the partners got me to an error page but it's clear that Ximian wants to make money by having people pay for having a red carpet channel.

    While I understand that they have to make money somehow, I find it very disturbing that the only way to get my software listed is to pay Ximian or to have it included in all distributions.

    Of course the software is GPL'd and it could be hacked to have a "add channel" menu (it would be really cool if clicking a link in mozilla or a file in Nautilus would do this) but such a patch will probably never make it into the distributions.

  • The problem with the ports system is the same problem as Slackware has: it works great, it's easy to use, it seems powerful, but it isn't a package management system. Why not?

    What version of smtp are you running? Well, without version support, it's hard to find out. (You could telnet to port 25 on localhost to find out.) Or, I can type: rpm -q --whatprovides smtpdaemon which tells me: sendmail-8.9.3-20 This gives me a central place to track software versions and dependancies.

    And, if I file a mysterious file or directory on my computer, I can find out what it does by asking the package manager! rpm -qf /var/spool/mqueue

    As you manage more and more machines at the same time, real package management becomes more and more needed. Dependancies are wonderful. Listing all the installed packages are wonderful. Being able to erase a package without a care is wonderful. The ports collection has a long way to go before it can handle these problems. (And, if you just want each package to be compiled from scratch each time, you source RPMs or DEBs.)
  • You will find that if you update your redhat to the latest vendor suggested update you will be able to install these rpms if you do not have other dependancies.

    Redhat Errata [redhat.com]

  • The strongest point it has for me is that it works.

    The RedHat updater has consistently crashed on my 6.2 workstation every time I have ever attempted to use it, through multiple versions.

    Red Carpet worked great first time, and finally updated some things I was deliberately leaving sit (because they weren't vital) until I could hit them with a GUI. I could have updated them manually, but I wanted to test the GUIs more than I wanted them updated.

    This is a good program. Anything that makes it easier for my grandma to use Linux means more cheap hardware and more drivers for me.

    -

  • Someone should moderate me down with "offtopic" or something so as not to confuse others.

    Guess I deserve to loose a couple of Karma points for jumping in with both feet.

    Macka

  • There is a standard package downloading tool for .deb and .rpm - APT. The Mandrake 8 beta we've been testing for the last month includes it as the common package downloading tool, and it works *really* well.

    Sign up to the mandrake-expert list to get details about where to download the ISO images and help test it.

    Oh, and re: Red carpet: with any luck, the functionality will be in libso, so if you want scripting, or you're an old-school Unix bearded guy, a command line version shouldn't be too hard.

    The big question is: will APT and Red Carpet resolve the installation of a package in a similar way? Will the package repositopries on Ximian match the distribution vendors (likely,, but still important) and (more importantly) the the third party application developers?
  • Things like Red Carpet (and the older HelixUpdate) really help out new users

    Red Carpet might 0Slashdotted so I can't see, and there's no Mandrake version - odd because Mandrake has the highest desktop share according to most surverys but Helix Update definitely did not help out new users.

    Because it force installed all its packages. And that *really* pisses a new user off when they find their system refuses to be upgraded because Ximian assumed their own packages would always be better. I'm angry the tool did this, I'm angry they didn't tell anyone, I'm angry about the wasted mailing list time to support the users who had their systems raped by Ximian.
  • * Mandrake 8 beta does it too

    * The tool basically exists because currently there are no quality GUI tools for APT (or DEB or RPM for third-party stuff, for that matter). If nobodies been bothered fopr the last couple of years, chances are they won't be in the future. Most non-Unix/BSD experiences Linux users would avoid remebering command line switches if they have to.

    * You could simply take the tool and craft it to use APT as a backend. I think this might be the way to go.
  • * IT satisfies dependencies by downloading and installing them (if you want). This removes the endless headache of hunting, downloading, and installing that it currently takes to update a single package (Gimp needs newer GTK, GTK needs newer glibc, etc)

    * It can easily install multiple RPMS simultaneously - you can't point kpackage at more than one file

    * It hopefully doesn't have stupid error messages like "KPACKAGE MUST BE RUN AS ROOT!!!" though it might. If I download it, run it as a regular user, and it gives me this sort of (pardon the language) shit (instead of just asking me for the password) I, like many other users, will uninstall it.
  • >Easy. Slackware has no package management system
    >to speak of.

    Last I heard, the definition of a "package management system" does not list a dependency system as a mandatory requirement. It is a feature of Slackware.

    (I'm a Debian user, but I'm equally comfortable with Slack.)

    >What's there has no dependency system, (which
    >drove me to Debian). Tools like this are totally
    >dependant on underlying package management
    >systems, and tgz doesn't cut it.

    Would it be better to say, that dependency system is required for the tool to run, and tgz is "not compatible"? Lacking a dependency database does not make it "not cut it".

    By the way, is there a dependency system that does not keep track of a database? Instead, how about one that looks for stuffs on your machine in real time? e.g. use 'ldd' to search for installed libraries and 'which' to search for installed executables.

    Although I don't know what to do with version numbers, does ELF provide a facility to store (a non-strippable) version numbers directly into the executable? If so it'd be great. Just like the version resources of Windows programs. One of the few features that I like. Another being the concept of the "Program Files" directory.

  • Mirror (Score:2)

    by aCC ( 10513 )
    Found it mirrored here... after Ximians download site is not reacting for me anymore.

    Binaries:
    http://www.mirror.ac.uk/sites/ftp.helixcode.com/ pu b/red-carpet/binary/

    Sources:
    http://www.mirror.ac.uk/sites/ftp.helixcode.com/ pu b/red-carpet/source/

    Debian apt sources.list:
    deb http://www.mirror.ac.uk/sites/ftp.helixcode.com/pu b/red-carpet/binary/debian-22-i386/ ./

    Have fun.
  • Now, a GUI tool for setting up and administering APT could be very cool

    That's what it is.

  • Aduva was just ludicrous, even when you don't count the fact that it totally screwed up my box.

    It was graphically over the top, and the first time I launched it, without any message saying "checking libraries" or something, it took about 10 minutes to launch.

    This is sweet, and it's pretty cool that you can use HelixUpdate to install it as well.
  • Ummm, this is pretty serious in my books. Admittedly, I haven't downloaded this yet, but if true then Ximian is ignoring a growing base of people that use Linux with X other than XFree. What about those running Xig, or (as in our case) the wonderfully stable and robust HP X? This package would be useless to me if it insisted on installing XFree...anyone verified this?

  • Why on earth are you still using dselect? Pretty much everything you want to do should be covered by apt-get install, apt-get dist-upgrade, apt-get remove, and apt-cache search.

    A lot faster, a lot simpler, and much less of a pain.

    (occasionally using apt-get autoclean is good to keep the package cache down in size, too)

  • ...I missed the ability to search/browse packages.

    apt-cache search is handy for quick searches.

  • Re:Bolt-on updaters (Score:5)

    by Fluffy the Cat ( 29157 ) on Wednesday February 21, 2001 @02:08AM (#415045) Homepage
    My problem is with the issue of bolt-on updaters. I personally have used these things before, and I have found that they are more trouble than they are worth.

    Define bolt-on. When it comes to Debian, for instance, you're merely replacing the package management utilities that come with the system (dpkg and apt) with another one that uses the same data files. There's no difference in the amount of underlying control over the operating system.

    I would not trust my operating system to a third-party updater; after all, given that Unix is a server OS, you should compile from scratch anyway (to ensure maximum speed and so on) - the value of this is limited.

    Ah, right - this would explain your confusion. You're missing the point entirely. Many people don't want to have to download and compile every piece of software they want to use. They want to be able to say "I want that" and for it to appear on their machine. This isn't limited to users. I admin over 20 machines consisting of 4 different architectures. If I had to compile everything by hand it would take me forever. However, the wonders of the Debian package management system mean that I can keep them running, up to date and secure while at the same time doing a full-time degree. Package management is a wonderful example of a labour-saving device. Don't knock it just because you're a die-hard "compile everything from source" freak.

    If you want this, you should get an OS where this facility is integrated; for example, Windows 2000 now has built-in management and update facilities, and this might be a more appropriate route to take.

    Uhm. Linux (in the shape of Debian, Red Hat, Mandrake, Caldera, SuSe, the vast majority of other distributions) is an OS that has had a package management system integrated for several years. The copy of AIX I have here from 1992 had a package management facility. Doing everything the long, hard, painful way for minimal gain is not the UNIX way.

  • Re:Can you belive the speed of this?? (Score:5)

    by Fluffy the Cat ( 29157 ) on Wednesday February 21, 2001 @02:11AM (#415046) Homepage
    Why would we need YAPM (Yet Annother Package Manager)??
    At the moment there are RPM's, DEB's (apt) and they are cool enough.. then there's the good old tarballs, and BeOS PKGs', then there's QNX' package manager, and loads of time..

    It's not YAPM in that sense. It interfaces with your distribution's existing package management system, presenting a uniform interface to it regardless of whether you're using Debian, Red Hat or SuSe while at the same time giving you various extra features that you may (or may not) need. It's not a replacement for RPMs or Debs, it's a replacement for things like dselect.
  • five bucks says Ximian and Eazel announce a merger within 6 months.

    Eazimian? Xeazel?



    --

  • Re:So what? (Score:2)

    by Anonymous Coward
    Hemos doesn't want to be among the 25% to be cut. He is trying to get Ximian to buy a banner ad.
  • Obviously, the KDE camp can't require use of another desktop environment to maintain its own. However, a KDE installer using the same backend "guts" as Red Carpet or Eazel's updater for its rpm and deb database maintenance and inventorying would be productive, such that the Qt/KDE and GTK+/GNOME/Ximian or Eazel installation systems are interchangeable.

    I imagine this would mostly be focused on the login/authentication and subscription management sides of things, since once you're past that, it is mostly leaving things to RPM and dpkg.
  • No need to immediately leap to conclusions.

    To quote Vladimir Vukicevic off Gnome News [gnome.org]: "One of the things that red carpet demands currently is that the database (especially for rpm) be in a consistent state. This is often not the case, especially on systems that have been around for a while."

    So if any packages have dependency problems which Red Carpet can't fulfil by installing a necessary package, it instead prompts you to remove them. Which means that if, for example, your installation of QT has a dependency problem (as mine did), you will be prompted to remove most of KDE.

    Rather than uninstalling, though, you can just sort out the conflict. In my case the problem was a hand-compiled version of Mesa (for my voodoo card). I should have built an RPM when I compiled it, but a quick rpm --justdb on a generic Mesa RPM left the files as they were but updated the database as necessary. Presto!

    (PS Future versions of Red Carpet will tell you more about the nature of the conflicts, and hopefully help you deal with them more constructively)

  • Which means if you like to stay on the bleeding edge (or help main one of the big packages like GTK+) this won't help you much. It seems to me that package management in general makes maintaining your system much more difficult if you run a non-standard setup. (Not that I'm knocking it; I'd never go back to slakware.)
  • > Want a GTK+ widget in the middle of your HTML page? Set up a custom tag for it and there you go. No mess, no fuss (well, not quite, but almost), and incredibly powerful .

    Didn't we crucify Microsoft for doing exactly this with IE some years back? Not that the tag was terribly nice looking, but the idea was sound. And the controls were even digitally signed. Maybe their fault was the folly of thinking this was appropriate for the public internet, but I remember plenty of people trashed the very idea behind it. Now 5 years later...
    --
  • Indeed.

    # rpm -Uvh red-carpet-0.9-0_helix_1.i386.rpm
    only packages with major numbers <= 3 are supported by this version of RPM
    error: red-carpet-0.9-0_helix_1.i386.rpm cannot be installed

    Fantastic.
    Maybe some day, I'll work out how to update my system enough in order to get this updater. *Sigh*

  • If you'd read the announcement, you should have known that no, it is not yet another package manager for a specific environment. It is a package manager that is not restricted to a specific package system (can for instance use both deb's and RPMs), and is not restricted to a specific distribution. As long as there's a channel available for your distribution or environent, you should be able to update almost anything with it.

  • Promote this tool! (Score:5)

    by Codeala ( 235477 ) on Wednesday February 21, 2001 @02:37AM (#415076)

    Even if you are a CLI true believer, tell your friends, co-workers and people on the street that: "Yes, Linux has many graphical updaters. And here is another one". One of the biggest misconceptions about Linux is that it is hard to maintain, "So many packages, so many patches/upgrades. How can I possibly manage this mess?".

    Things like Red Carpet (and the older HelixUpdate) really help out new users who just want to be told what to update (and why). HelixUpdate (don't have RC yet :-), shows a list of available updates organised by importance (security fixes, bug fixes, new packages etc) and with brief explanations on what they are for. I don't think there are similar programs for Windows (or Mac?) that let you check for updates, not only for your OS, but other applications as well.

    With RC and most under Linux updaters, they provide updates for many common packages so you can update your browsers, irc client and print software all at one go (actual example). If this isn't ease of use, I don't know what is.

    ====

  • * IT satisfies dependencies by downloading and installing them (if you want). This removes the endless headache of hunting, downloading, and installing that it currently takes to update a single package (Gimp needs newer GTK, GTK needs newer glibc, etc)

    And herein lies the value proposition.

    The traditional method of keeping your RPM packages updated:

    a) keep track of new release announcements
    b) find the RPMs for your architecture and distro
    c) download all of them, one by one.
    d) try to install them
    e) find out that the RPMs you just downloaded require package foolib0.6.8, when you only have foolib0.6.7, and have no idea what foolib even is.
    f) do an rpmfind search for foolib, finding 0.6.8 RPMs for every distro but yours
    g) track down foolib on freshmeat, but find that its info hasn't been updated in 6 months, and the homepage link to some scary URL like http://students.rthu.ru:73473/~bruno/sw/foolib.htm l is 404 outta order.
    h) completely kick yourself in the ass for wasting all that time when you type in http://www.foolib.org/ and the RPMs are right there waiting for you.
    i) download and install foolib
    j) install the other RPMs - the ones you were trying to install in the first place.

    The Red Carpet way:

    a) select the newly available packages you'd like to install
    b) click 'install packages'

    Hell yes, that would save me eons of time and endless amounts of frustration.

    And yes, I'd pay something like $25/year for such a service.

    * Note to Debian evangelists: why yes, I've heard about the wonders of apt-get :) I'm even building a Debian box here so I can see for myself. In the meantime, I have RPM-based systems to deal with.

    --
  • A big part of the Microsoft bashing came from the lack of security inherent in the scheme. In particular:

    1) ActiveX stuff could do whatever it wanted with your machine

    2) The digitally signed stuff was a joke at the time. All you had to do was submit a credit card and address, and they'd give you a signature.

    3) When someone pointed this out to Microsoft and eventually the Seattle Post-Intelligencer, the response from Microsoft was "The security would be too hard to fix, and we'd like you to meet the Verisign legal team."

    Go see Fred McLain's story [halcyon.com] at http://www.halcyon.com/mclain/ActiveX/welcome.html .

    Somehow, I feel like I should expect to meet the Verisign legal team soon. From what I've heard, Verisign has become more careful about the signatures. And as we've all heard, Microsoft still thinks fixing security holes is too hard to be worth the effort (to be worthwhile for their shareholders, of course, since they are publicly held).

    -Paul Komarek

  • What does this do differently than kpackage?

    I'm not trying to troll here, I really would like to know.

    K45.

  • Missing feature (Score:3)

    by AT ( 21754 ) on Wednesday February 21, 2001 @08:38AM (#415089)
    One thing that seems to be missing from Red Carpet (as well as any other tool i've used) is a summary of changes between the version installed and the updated version. That would really kick ass.

  • Re:Only a Workaround (Score:4)

    by MartinG ( 52587 ) on Wednesday February 21, 2001 @02:45AM (#415090) Homepage Journal
    yes, but if you provide the same interface to everyone, then eventually they start to care less about whats actually happening underneath as long as it works well.
    Eventually then, this means you could standardise on one package management system underneath without forcing the users to learn a new interface. I still don't think you're going to get debian to switch to rpm or rh etc to adopt .deb overnight, but a unified interface eliminates a large part of the problem, so although as you say it's only a workaround, it's still a step in the right direction.

  • Re:Only a Workaround (Score:3)

    by avalys ( 221114 ) on Wednesday February 21, 2001 @02:51AM (#415094)
    The distro provides you with package management tools, there's only one database (because all these updaters use the package managers to list the installed software and install new things. Perl can be installed at install time, and GNOME is installed with Helix's very nice updater (why isn't it graphical for debian, though?).
  • "Dude, there is a bug in GtkHTML."
    "That isn't a GtkHTML bug."
    "Yeah dude, it is.
    "Dude, no it isn't."
    "Dude, it is."
    "No, dude, it isn't."
    ...
    Yep, had that conversation with the GtkHTML guys. A couple did turn out to be their fault, though ;) Seriously, GtkHTML is a seriously cool piece of software, and the project I hack on, GnuCash, is make ever-heavier use of it. Want a GTK+ widget in the middle of your HTML page? Set up a custom tag for it and there you go. No mess, no fuss (well, not quite, but almost), and incredibly powerful . . .

Slashdot Top Deals

If you think the system is working, ask someone who's waiting for a prompt.

Close