On Sun, 16 Mar 2003, Marcus Leonard wrote:
> But... redhat-config-packages will > (a) install _any_ package from the file manager (I know there are > dependency limitations, but let's keep going) > (b) apparently not keep track of these non-RH-CD ones I already brought this up on the list in a previous thread. Though, it would be hard to search for the thread by the fact i posted to it..considering how much drivel i post. But Havoc responded, so looking back in the archive for Havoc's post will probably find it. It looks like r-c-p isn't fully baked yet in terms of how it handles 3rd party applications. The reasonable options I see, is to expand r-c-p to at least list non Red Hat packages, so you can uninstall them by hand. Or lock r-c-p down so it doesn't install 3rd party packages at all. Or maybe have r-c-p warn you with 14 "Are you damn sure, you want to do this" dialog boxes when going to install 3rd party rpms. Right now r-c-p is kinda of backwards, it would be far better if it listed 3rd party rpms so you could account for them, but shouldn't be able to install them so easily. > This gets back to a mismatch; I think the messages should match up with > the behaviour. This is a simplified, apparently "safer" RPM manager. But > you can still easily install non-official-CD packages, and it doesn't > even track them. And if security and QA are so important, then why is it > so easy to install another RPM manager and mess the whole thing up? Well I for one, think its a bad idea to be able to point and click yer way to a 3rd party package manager out of the box. I'd much rather see the system locked down at the gui level...forcing you to drop to commandline to do "advanced" operations. But that's unrealistic in the long term. There needs to be a way to provide and install 3rd party packages that addresses these issue...all i can think of is a rather intesive file layout redesign that allows for 3rd party rpms to be installed in a sort of sandbox area, so that Red Hat packages are not obliterated, but that's really complicated and makes my head hurt. > "Well, you have to draw the line somewhere." I agree, but why not draw > the line clearly? This current method doesn't guarantee you QA, in fact, > as it stands, it may make it much harder to encourage QA because it > doesn't track what it allows. Yep...r-c-p is bizarrily limited. But Havoc's comment to my thread about r-c-p, seems to suggest that there is no evil plot in the works to limit users...its just that r-c-p isn't fully baked. > The important part is clearly stating what you're about. The advantages are > (a) expectation: if users are warned that they're going into unsupported > territory, they either won't try it or won't expect you to help them (as > much...) if they do. how the hell do you do that...nobody reads the documentation. > (b) avoidance of extra work: you stop fielding so many help requests I'd much rather field questions about how to get apt-get so I can tell them it ain't supported...then field questions about how to recover when apt-get munches their system. > Me too. Why not have a package manager with two levels? It defaults to > simple/newbie mode. If you try to install something non-official, it > either won't do it or warns you with something scary like "Are you sure > you want to install this? It's non-official and no-one at Red Hat will > speak to you if you do!" That would have put me off in my newbie days. > (For a while...) The second level is one you consciously choose to let > it do whatever. I'm thinking that, with all of the package managers > around, making something fit this spec wouldn't be so hard. It would be > an attempt to recognise the practical realities of using GNU/Linux. I would go further than that...I would want a package system that knows about preferred vendor heritage for packages. I would go further still and have a package system that lets you install/upgrade vendor approved packages in a different way then unapproved packages, so that users could install an application, and even a chain of dependances to some extent, in an unpriveledge way...so the Red Hat packages do not get disturbed. The specifics of how to have 3rd party packages safely downloaded by end-users is one that has to be addressed before Red Hat can focuses on the home-desktop market. Clearly in the home desktop market, there is going to be a desire and need for easy install of things like proprietary add-ons that Red Hat isn't going to ship, (right now in the hobbyist desktop market..there is a desire...but no true need..since hobbyist know enough to get the job done without a default tool in the distro) My cyrstal ball isn't so clear as to how Red Hat will address this desire when finally focusing on the home desktop market in the year 2014. But I think fedora has the right idea when approaching QA. If I had to guess i would guess that Red Hat, would develop some sort of "partner channel" model where 3rd party binaries (and maybe sprms too) would have to conform to some QA tests to get access to the channel structure. I am hopeful that the fedora project, even though a community based idea, and not an internally sponsered Red Hat one afaik, might lead the way and might even get the blessing of Red Hat, as a secure way to get unsupported add-on packages, especially if there are tools in place that do a good job of telling end users where the package came from...so support issues can go to the correct vendor. If the crux of the reason Red Hat doesn't include apt is really security and a garuntee on minimal QA standard, fedora seems to be the answer to those issues. But as it stands, the issues raised in the faq, seem to be a problem for all the rpm management tools out there, though to be honest I haven't tried red-carpet in a long long while, and I had a little birdy tell me there were improvements in the works along these same sort of lines with red-carpet...so take this last comment about "all the current management systems" with a dumptruck full of salt, as compared to the standard vw beetle full of salt, you should normally take with my comments. -jef"happy saint urho's day!"spaleta -- Phoebe-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/phoebe-list
