Slashdot Mirror
Is It Time To Change RPM?
Floris pointed us to an excellent article over at Freshmeat discussing the
problems with RPM. It compares RPM to the other alternatives (mainly Debian's apt system) and discusses where the problems are. It's not a distribution war thing, this is a serious problem that needs discussing. Read the story and chime in.
the "do-everything" button was an abstraction. you should have realized that.
i've read many of your comments, and agree with quite a few of them, but your views on what a package management system should be able to do for the user are off the wall for reasons already expressed by myself and others.
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
Not at all. What I'm saying is that the pre-existing packages are no advantage, because you'll have to make new ones to support the exapanded functionality. Which means that the primary motivation given for trying to make .rpm do these things instead of simply using .debs for their distribution is specious. Why re-invent the wheel?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I think a lot of these features would be great. that is the great part about open source software. if people want some of these features. people can always write them and contribute.
-- I doubt, therefore I might be.
Firstly, it's not easy to update the ports tree itself
You're going about it the wrong way there. Have a look see at the FreeBSD Handbook for CVSup for more details on this. Also, if you don't already have a copy, go pick up "The Complete FreeBSD" from Walnut Creek. It's an outstanding book, and one that I found to be a much easier read than many of the Linux specific books out there. It has a chapter covering the ports tree that I think you'd benefit from.
Mind you, ports do have their problems. All in all, I think that it's a far better approach to software distribution than anything else that I've seen. A more in depth discussion of this, which even relates to this thread, was done a few weeks back right here on Slashdot, "Unified BSD packaging system?". One of the concepts brought up in that discussion I haven't seen mentioned in this one is if there is some way to unify all the *nix world rather than just the various flavors of Linux.
It sure would be cool to see a group work out the best of the best features from the leading methods of distributing software and bring it to all the platforms. Definitely not holding my breath for anyone to actually do this, just a pleasent thought just the same.
The line must be drawn here. This far. No further.
It is infinitely configurable. But Linux, along with the other unices, is made to be a server - and servers are made to be used by users, not administrators (they have their own user accounts). The users are definitely used to the common directory structure. Sure, you can do whatever you want your own box, but your users might not know what the fsck is going on.
-Leo
> One famous saying that applies to Linux is this: too many cooks spoil the broth. With the thousands of driver modules, library modules, and executables, Linux is one big mob of code.
... ?
What you're saying makes no sense. Linux is not one big mob of code, it's the exact opposite. The code is neatly divided into pieces, each piece serving a different purpose. This way each team can work on a specific piece of software, with minimum compatibility problems.
The difference between Linux and Windows in that aspect, is that while Linux packages different programs/libraries/whatever in different packages, Windows "is one big mob of code", with *everything* distributed as one huge package.
> It's surprising that it's as stable as it is;
In that case, Linux vs. Windows is just an exception to the rule, right? I suppose then you can provide other examples then
> it's not surprising that it's as hard to upgrade as it is.
Obviously you're not using the right distribution and/or the right tools. I can upgrade my entire distribution to the latest cutting edge software with `apt-get update; apt-get -y dist-upgrade`, then come back later when the download is complete, and take 5 minutes to configure it.
> Microsoft doesn't dole out the DirectX SDK out freely (or do they?
Yes, they do: DirectX 7 SDK
If game developers had to pay for it, it would of seriouslly put a dent on DirectX becoming the standard Win32 hardware acceleration API.
In my opinion, the problem with RPM is that the documentation is falling behind. The book 'Maximum RPM' is of very good quality but it hasn't been updated since RPM 2.0 days really and so many things have changed or features have been added. For example, the relocatable packaging feature has been greatly improved. Macros and triggers have been added. The latest RPM can do automatic gzip or documentation, strip binaries and do additional checks. All this leads to RPMS of varying quality because they come from various sources, each with differing opinions and standards. If you want to see how bad it is, just use the program 'rpmlint' or a typical RPM package and see all the warnings it gives you.
Sorry, I don't really use perl. My bad . . .
-Leo
I hate to be involved in the Debian vs RPM based distro holy war, but Debian's packaging system is one of the things I think makes it so much better.
A slip of the foot you may soon recover, but a slip of the tongue you may never get over. -Benjamin Franklin
hmmm... interesting theory here. I don't believe that rpm's were made for this intended purpose, but you do have a point. Debian upgrades are a breeze compared to rpm distro's. Once Debian is installed there is nothing but upgrade from there. Just point apt-get to the right place and there you go. Redhat might not like it if people only bought a distro once and then just apt-get distupgdraded it from there.
Debian, being completely non-commercial does not have this concern. I don't use Debian as my desktop because it's not as cutting edge as I like, however, if you run it as a server it minimizes administration hassles and it makes maintaining your box much easier.
my fault
-rev
Ports is indeed a very cool system, but there are one or two wrinkles.
/usr/ports
Firstly, it's not easy to update the ports tree itself; either I'm dumb or the documentation doesn't tell you how to do it. I'd like to be able to do something like this:
$ cd
$ make update
And magically, version numbers update and new packages appear.
Secondly, ports doesn't seem to support any kind of history on the packages; you get the latest version that your ports collection knows about and that's it.
Thirdly, there seems to be no way of verifying the installation of a particular package; like rpm --verify.
I'm sure that these things will get straightened out in time (or not if they're dumb ideas).
--
Peter
That's an excellent idea! ok, but now it's time to rewrite anything that depends on certain things being in certain places. number one: the linux kernel expects init to be in one of several places which include /bin/init, /sbin/init and the like - but if it's not there it will panic (but only if it can't find a shell to dump you into first, which is likely if /bin is not /bin). However, if you just want to change directory names, use symlinks - you don't need a config file for that.
-Leo
It really install to /usr/local/bin? Then the distributor of Quake2 is violating FHS. The whole packaging system is not supposed to touch the /usr/local directory!
The problem with that is, after a year or two of installing applications from tarballs you have shit strewn all over your box, incompatible library versions, and generally no version control system. It's a mess. At home on a personal system that you don't care about it is fine.. you can always wipe the system and reinstall every year or so, but on a production system you need more control over your packaging.
Oh, you mean, like debconf? Well, IIRC it's not XML, and there's still a fair number of debs that don't use it, but the functionality is mostly there.
It provides an interface for front ends to ask you config stuff for packages, and stores your answers in a database-- it won't ask you the same questions again, unless the packager makes it do so for some important reason. It's configurable in the level of questions it will ask-- ask only critical stuff, and go for defaults on the rest, ask everything, and a few points in between...
Where you do bring up some good points here, the basic concept of what you're talking about just isn't desirable. Let's work through your example, which is a fair one to be sure.
On the destkop, a user who, on Christmas morning, getting messages that Barbie Magic Funhouse can't be installed because it conflicts with sendmail and will break dependencies for Evolution is complete, utter and total, unadulterated failure.
It seems that you are referring to a Windows based install here, or at least that's the premise I'm working from. It's quite likely that this Barbie program is going to require DirectX of some version level, as well as other possible shared libraries from Windows. What does the software OEM do in this case? They include on the CD any of the possible shared library versions that may not be up to date, then the installer looks to see if it needs to upgrade the system or not.
Certainly the weakest point of RPM's is that they are simply awful at dealing with library dependancies. That doesn't mean that this problem can't be resolved, it just means there is a problem. The BSD folks recognized this problem a while back, and address it quite nicely with their package and ports system of installation.
Coming back to this example, in the FreeBSD world if a library equivalent to DirectX were to be needed by this Barbie program, the package would go and hunt down that dependency on the Internet. It's pretty powerful stuff, and goes a long ways to working around the problems that you've brought up.
To date, I only have experience with RPM's and FreeBSD's system of handling installations. I understand that Debian's package management has similar dependency finding capabilities. It's probably fair to say that none of the present solutions now being used are optimal. I would include even Windows installs as problematic in this regard, and anyone who has run into "Can't find VB400RUN.dll" before can certainly appreciate this.
I am of the belief that a truly optimal system can be developed, just based on what I've seen to date. Where I have hope here, I also have a great deal of doubt that the various groups backing their preferred method can step out of their foxholes long enough to work towards that.
Bottom line, there's more going on out here than just RPM's not finding dependancies. Have yourself a look about, there are some very cool things that are already in place, and in work.
The line must be drawn here. This far. No further.
That's what symlinks and shell aliases are for. And bash's default config file aliases ls to dir for all you DOS people, so you don't have to think too hard ;)
-Leo
> security.debian.org does make it possible to install only security fixes on a stable system. That's an important but very limited case. It doesn't help if I replace security with any other criterion.
... ?
Can you give example of another criterion?
> Moreover, what if I'm running unstable? I often do this, but there are still times when I don't want to risk installing any upgrades but critical ones.
Why are you running unstable, if you want to only risk installing critical updates?
> hold is a very blunt instrument. For example, if I install version 1 and put the package on hold, I will get alerted by deselect when version 2 comes out (ie, it will appear in the "Updated" section"), but if I choose not to upgrade, I won't get any new indication when version 3 comes out. I have to remember that version 2 was the last version I considered.
I could be wrong, but I think `apt-get dist-upgrade` will tell you when a potential upgrade is being put on hold.
> Debian stable does not contain only well-integrated, well-tested packages. If you think so, you're either horribly biased or smoking something. Think about GNOME in slink. Or the many orphaned packages in any stable release. Or all the random little programs used by almost nobody and packaged by novice Debian developers.
*shrug*. I don't use stable, so I wouldn't know. Unstable is plenty stable enough for me. Perhaps someone else can comment
at some site called slashdot...4 210&mode=flat
http://slashdot.org/article.pl?sid=00/09/13/063
funny how that article got one (abusive) comment and this one got hundreds, they're essentially about the same thing.
Anyway for what its worth - I think all the people thinking about this shit should talk to each other more. Theres not just rpm, deb, and that bsd development, but things happening on the fringes like the rpm-for-cygwin development (http://cygwin-rpm.sourceforge.net/ yay, no more searching through the list of ported software) and loki games' setup tool (http://www.lokigames.com/development/setup.php3)
ask why a new version of a package was released?
see a list of changes between old and new versions?
Well, RPM does include a Changelog which should include why the package was released, and what changes were made. check the --changelog option.
tell the system to apply only security or high-priority fixes?
You can do this mostly by installing a distro, and then tracking a particular version of it. Redhat-6.2 has lots of updates, but all of them fall into your 'security/high-priority' category.
tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?
It's trivial to setup something like this where you mirror the appropriate dir on updates.redhat.com, then have a script which does an rpm -F foo.rpm on every rpm whose name isn't listed in 'no-auto-upgrade.txt'. However, given your original statement, it's not possible. You're saying that you want it to automatically everything, except it should psychically know what you want to pick and choose from. Ummm... no matter how you cut it, you'll at some point have to tell the system 'upgrade or no'.
tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?
This is the default behavior of RPM. You have to use --nodeps to override it.
ask for packages that will help me convert GIF files to PNG?
You want natural language capability search built into your package manager? You've watched too much star trek. If however you did a quick search for RPMs that contained both 'GIF' and 'PNG' in their name on a site like rpmfind.net you'd find gif2png is readily available.
ask for only packages targeted at beginners?
I have no idea what use this is. Beginner is a very broad term. Is Enlightenment aimed at beginners? How about Windowmaker? The answer for both is a resounding maybe!, depending on the configuration. How about gcc, is that for beginners? After all, most computer barely-literates don't know how to use a compiler. And bind, that's definitely an advanced package right? unless of course you install a caching-nameserver rpm that helps the beginner have their own caching nameserver, then it's beginner. Or an obvious beginner package like grip, whcih isn't beginner at all, i mean, you have to know about mp3 encoders and cd rippers.
ask for only well-integrated, well-tested packages?
Use RedHat, they'll only give you these. If you stick to basics, unless you use Mandrake, you usually won't get anything that's not well-tested and integrated.
get reviews of a package?
Ah yes, all programs expand until they read mail. Or in your case, you're asking for the package manager to read newsgroups and mailing lists, so it'd be a newsreader too. Maybe we should just integrate this package manager of yours into emacs.
find out how to get started using a package?
The RPM format allows for certain files to be flagged as documentation and generally installs them in the path /usr/doc/$rpm_name. and man files in /usr/man. you can get a list of what it installed by doing rpm -qi package_name.
begin browsing the documentation for a package before approving a full installation?
again, you're asking the package manager to do things that just don't make sense. Why not read up on the software, then install it? Or just install it, and if it's no use to you, do an 'rpm -e'.
have some help in configuration updates?
These are called man pages, and documentation files. You read them and they help you. Or hell, if reading real documentation is too much work for you, then see if there's a HOWTO that you can peruse somewhere on the net.
Personally I use FreeBSD which has it's own unique set of strengths and weaknesses, and if you don't think anybody out there is thinking about this stuff, you should read this document which is a summary of the state of these things in FreeBSD, and some ideas on how to progress.
----------------------------
I LOVE rpm! What could be easier than rpm -Uvh file.rpm?
apt-get install package.
Try downloading gnucash and install it. It will fail with a bunch of dependencies. Of course, it's close to impossible to find the where those programs/libraries are, and if you find them, you can't find the rpms for them.
In Debian, 'apt-get install' will retrieve the dependencies too.
Je ne parle pas francais.
Say something useful.
If it's compatibility you want, have a look at "alien".
--------
"I already have all the latest software."
apt-get/.deb/dselect are SOOOOO amazingly cool.
I like to put it this way:
RPM is what windows install/uninstall was meant to be.
apt-get was what RPM was what meant to be.
Quando Omni Flunkus Moritati
That's unfortunate, because nobody cares about NoMad Linux.
Packaging (and shared code) inevitably causes more problems than it solves. Maybe a few geeks like us would appreciate the better use of resources that shared code gives. But most users (and probably a few geeks as well) would be better served making each program its own seperate entity--One program, one set of code. Some will no doubt decry my advocacy for static linking (I'll make an exception for things like glibc), but take into account that Linux is starting to get into the regular consumer market. The regular joe, home consumer market has a totally different set of rules and goals than the workplace IT market. And currently, I see the linux movement making a very large mistake by approaching the desktop market with the same exact strategies and objective as the server market. Success and failure in the two markets is very different. On the server, a crash is failure. Some script kiddie rooting the box is failure. On the destkop, a user who, on Christmas morning, getting messages that Barbie Magic Funhouse can't be installed because it conflicts with sendmail and will break dependencies for Evolution is complete, utter and total, unadulterated failure. And up to this point, the linux community has done nothing but bury its head in the sand and try to rely on the internet to solve problems that static linking could easily solve. The funny thing about the word "dependency"--it usually comes after the words "co" and "drug". Seriously, ask 1000 people outside a CompUSA what they would rather have: An OS that uses their memory and disk space more efficiently, or an OS that lets them install as much software as they want without breaking anything and which will never preclude the installation of any other software. 999 of them will go with the latter. Most people want computers that simply just work. This is The Reality That Is The Desktop.
sbin??? I seriously hope your users don't expect a statically linked perl. As for the "right" place of perl, there are many. /usr/bin/perl and /usr/local/bin/perl are common, depending whether your vendor shipped perl with the OS or not. However, another common place is /opt/perl; common enough for perl's configure to use a different file layout for installation prefix paths with and without perl in them.
There is a reason for (almost) everything in *nix based systems, including the organization of directory structures. this was all "planned out" - well evolved actually
It maybe be evolved, but it has evolved in a huge mess. There's /bin and /usr/bin, and /sbin and /usr/sbin. Where do we find a shell? On some systems, in /bin/sh, others quote some standard and put it in /usr/bin/sh, and yet other systems have /bin symlinked to /usr/bin. And binaries go in bin directories, while libraries go in lib? Sure, but what's sendmail doing in /usr/lib then? /etc is for configuration files you say, but what are all those executable programs doing in /etc and below? (Some systems have more of them than others).
Every UNIX vendor and every sysadmin has its own idea of a proper layout. And the result is that you have some vague idea where a certain file might be located, but there's a myriad of exceptions.
You are in a maze of twisty little Unices, all different.
-- Abigail
I will take a look. Told you I was being dumb :)
/usr/ports/updateports.sh" or something and all the hard bits are done for me...
This perhaps needs to be mentioned more clearly in the handbook section on ports; even better, wrap it up in a shell script so dummies like me can do "sh
A platform-agnostic packaging system is desperately needed. I'd do something about it myself if I didn't have the coding ability of a sleeping snail.
--
Peter
You use NFS, AFS or some other shared file system. Or in case the servers are connected by sneaker net, tapes.
-- Abigail
If you've ever used a Real Operating System such as VMS or even maybe a not-so-Real one like Solaris, you'll find that the package management tools are pretty good - and vast wads of documentation are available for them.
Naturally, VMS has the best one (PolyCenter) but the pkgtool that Solaris has isn't bad either.
But the point is these tools are not akin to a bootloader in simplicity because the problem they attempt to solve is not a simple problem.
--
Peter
How about...
rpmfind gnucash
That'll take care of the dependencies for you. Or even better, use Helix Code's updater (of course that only covers certain desktop apps currently.)
That's not quite what I meant by "function". The dependency is still on something called "smtp-daemon". If something with that name is there but it doesn't function in the way that the package expects, it's completely undefined what happens. Maybe the user will get an error message at some point, or maybe his mail will just disappear. Depending on a package called "smtp-daemon" or on a file called "/usr/lib/sendmail" both is error prone.
yeah you. Making things easier to use (adding post-install script running to rpm) is NOT dumbing things down. You haven't done shit hardwork for Unix or anything else. Making the OS a challenge to use DOES NOT PROMOTE THE ASSERTATION THAT IT IS POWERFUL. If the OS or the system-level tools are a crudge then the system is useless to anyone who wants or needs to get real work done. Moving files back and forth and listening to MP3s is not real work. Administrators also do not like difficult to use systems, it makes their job ten times harder. Having a single program keep track of all your apps and files needed by the system is a great boon to someone without an infinite amount of time to write, debug, test and impliment a script to do the same thing. Hey is your mom calling? You better go do the dishes.
I'm a loner Dottie, a Rebel.
On a slightly different topic, how is it that everyone's getting along so well on unstable? I tried 'apt-get dist-upgrade' on unstable (after installing a fresh Debian system) and the next time I rebooted, my system was so screwed that I decided to wipe the drive and start over.
I was somewhat wondering how safe it was that it was installing IPv6 stuff in netbase as I saw it scroll by, and sure enough, after the reboot, the network didn't work. And not having access to the network somewhat left me stranded.
Was this an extreme circumstance, or is this the kind of thing that eventually happens when you run unstable?
--
No more e-mail address game - see my user info. Time for revenge.
Win dain a lotica, en vai tu ri silota
It's not perfect but it's some of the way there. It also has autoupdate functionality in the latest versions.
... 28.8 Kbps PPP connection]
- 1.0.1-1.i386.rpm
R edHat/RPMS/ImageMagick-3.9.1-1.i386.rpm
r t/RPMS/giflib-3.0-2.i386.rpm
g iflib-3.0-4.i386.rpm
R edHat/RPMS/libgr-progs-2.0.13-4.i386.rpm
/ 1998052417/RPMS/imlib-1.4-1998052414.i386. rpm
/ 1998052417/RPMS/glib-1.1.0-1998052414.i386 .rpm
/ 1998052417/RPMS/gtk+-1.1.0-1998052414.i386 .rpm
/ 1998052417/RPMS/gnome-libs-0.13-1998052414 .i386.rpm
/ 1998052417/RPMS/balsa-0.2.0-1998052416.i38 6.rpm
/tmp [Y/n/a] ? : n
------------------------------
[ from the rpmfind website ]
$ rpmfind -q --upgrade balsa
[search for approx 30 seconds
Installing balsa will requires 9574 KBytes
### To Transfer:
ftp://rpmfind.net/linux/freshmeat/libpng/libpng
ftp://rpmfind.net/linux/redhat/redhat-5.0/i386/
ftp://rpmfind.net/linux/redhat-labs/gnome/suppo
ftp://rpmfind.net/linux/contrib/hurricane/i386/
ftp://rpmfind.net/linux/redhat/redhat-5.0/i386/
ftp://rpmfind.net/linux/redhat-labs/gnome/devel
ftp://rpmfind.net/linux/redhat-labs/gnome/devel
ftp://rpmfind.net/linux/redhat-labs/gnome/devel
ftp://rpmfind.net/linux/redhat-labs/gnome/devel
ftp://rpmfind.net/linux/redhat-labs/gnome/devel
Do you want to download these files to
$
A rich XML based syntax? Just a pet peeve of mine, but why does everything have to be XML based? It's like Microsoft saying that C++ is the first language to have the ability to have XML-based comments embedded in the code. Yep, it is. But is =head1 really any better or worse than ?
As for your requests for functionality, perhaps you should read Installation and package tools document, version 1.0 by jkh over at the FreeBSD side of the world. While I know I'll be burned at the stake for saying good things about FreeBSD on slashdot, that document has some excellent thoughts which the Linux world could also benefit from.
----------------------------
Who are you to tell what the "Linux Community" is should or shouldn't do? If the both KDE and GNOME teams decide to spend the rest of their natural life writing notepad clones, guess what? You don't have a say in the matter.
You're not paying them to do what they're doing. And just because you happen to use somebody's program, don't pretend that the author 'owe' you anything.
As to dependencies. You must have a lot of time on your hand. I fail to see what I can learn from the fact that application Foo depends on library FuuBarLib.so.1.0.2.5-1 and FaabarLib.so.3.32.102.2, but won't work with FuuBarLib.so.1.0.1.4-3. Of course, since most of the time, the documentation (if there are any) only mentions that it depends on FuuBarLib.so.1.0.2.5-1. Nowhere does it mention where this particular library is found, nor what the package it might be found in.
And what are you doing, using RPM if you want to know what is installed on your system? Just roll your own distribution and feel really 3L337.
Remember, just because something is properly installed on your system, doesn't mean that you can't download the sourcecode and check it out. You just don't have to do it if you don't want to.
Je ne parle pas francais.
From the Freshmeat editorial:
...it would be a valuable addition to RPM to provide some mechanism to configure all unpacked but unconfigured packages. Pre- and post-install scripts, as well as pre- and post-removal scripts, should be executed appropriately to allow smooth upgrading of running services. Package maintainers would have to add such scripts to their packages and make sure they'll not break the system the package is being installed on, keeping in mind the diversity of RPM-based distributions out there. Auditing, predependencies, package flags, and auto-deconfiguration functionality must be implemented.
RPM packages can't be configured interactively. They won't ask you if you want to keep the current version of a configuration file, install a new version, or compare the two versions. They won't stop services before updating and restart them afterwards. The MTA won't ask you a few questions and configure itself. They won't even issue a warning to the administrator. We need to walk one more step to have it work properly.
This doesn't sound like someone acquainted with RPM's script-calling features to me.
DirectX 5.2 I think. It came with a book I bought called "Inside DirectX" by Microsoft Press. I believe they give it out for free at the DirectX website though.
-Justin
There is, dpkg. If you don't want to use Debian, Stormix and Corel is using this package system too.
Je ne parle pas francais.
One famous saying that applies to Linux is this: too many cooks spoil the broth.
Do you know what that saying even means, or did you just stop thinking at the "too many" bit? Don't worry, I already know the answer.
With the thousands of driver modules, library modules, and executables, Linux is one big mob of code.
And you think that it would be less code if the drivers, libraries and programs were globbed into one giant 2GB file? And just as flexible? And just as maintainable?
It's surprising that it's as stable as it is;
Excuse me? Being split up into clearly-defined modules, each focused on a single task, is likely to make something less stable in your opinion?it's not surprising that it's as hard to upgrade as it is.
Hard to upgrade? If you want just a couple of things installing, then it's not hard to click a few RPMs or just use apt or whatever. If you want to upgrade across the board, then just pop a CD in, boot from it, and most distributions will ask you if you want to upgrade. I don't see Windows being any better in this respect, yet I see it as being less flexible.
When I begin coding software
Oh, so you are new to writing software? I never would have guessed, I mean you show such a flair for good design.
I will keep modularity to a minimum
And reinvent the wheel every time you write a new program? Or do you think that if you link statically, your code isn't modular?
and I will never code for Linux or release my source code.
One word: gutted.
Since you are new to software development (assuming you aren't trolling), how about you accept that there just might be the slightest chance that people with more experience and skill have put more than a little thought into how both systems work. Then examine how each system works and learn from it. I'm pretty sure you'll find that Windows is a lot more modular than you think.
Well, considering the fact that RedHat and the commercial distributions business model is not to make money on the CD but rather the services, it shouldn't matter much.
And even though apt-get is great, I wouldn't be using it to upgrade a whole distribution if I was on a dial-up line (I'm sorry, but I can't wait 15 hours+ to upgrade/install my system).
Je ne parle pas francais.
Because it would be very difficult for Redhat to switch their entire distribution to dpkg. It would be much easier for them to add the additional functionality, and just update the packages to support it, rather than remaking them from scratch.
Of course, I'd *much* rather see everyone switch to dpkg (I'm a Debian user myself), but I just don't think that's going to happen.
get reviews of a package?
Ah yes, all programs expand until they read mail. Or in your case, you're asking for the package manager to read newsgroups and mailing lists, so it'd be a newsreader too. Maybe we should just integrate this package manager of yours into emacs.
Why does the packager have to write the reviews? Couldn't there exist a site that allows users to rate packages the way IMDB.com rates movies, Amazon.com rates books, or Flashline.com rates components?
chattr +i makes the file immutable, +u makes it so when the file is deleted, the contents are saved.
or if you're in the BSD land, then it's chflags schg to make the file system immutable, sunlnk to make it system undeleteable, or ucgh/uunlink for user immutable/un-deleteable versions of the above.
----------------------------
> On a slightly different topic, how is it that everyone's getting along so well on unstable? I tried 'apt-get dist-upgrade' on unstable (after installing a fresh Debian system) and the next time I rebooted, my system was so screwed that I decided to wipe the drive and start over.
:-) Never tried IPv6 in Debian. I personally don't think I've ever ran into a problem from installing a new unstable package that I wasn't able to repair, though.
Well, I'd imagine upgrading from stable to unstable is likely to require a lot of reconfigurations. To maintain a system running unstable is no big deal though.
> I was somewhat wondering how safe it was that it was installing IPv6 stuff in netbase as I saw it scroll by, and sure enough, after the reboot, the network didn't work. And not having access to the network somewhat left me stranded.
Yikes.
So you're saying it's easier to debug code when it's all bundled together in one big mess, then when it's divided into different pieces, each piece serving a different purpose?
I'm not really much of a programmer, but I know enough about programming to know that it's much easier to debug a modularized program rather then a program which is one big blob of code.
Correct me if I'm wrong, but what you seem to be saying is that Linux *should* be unstable because it's modularized ("one big mob of code"), and that Windows *should* be stable because it's less modularized and not seperated into individual packages. Is that right?
--
see a list of changes between old and new versions?
Grab the version of aptitude on unstable. In the screen that shows the data about a package, you can hit 'C', and it will download and display the Debian changelog for it. This is the closest feature to that available.
Unless you count the fact that in a BSD ports style system, you can look at everything in the source before you decide to build and install...
Yeah on a board full of 15 year old Linux zealots mentioning Office 2000 is silly but hey, fuck you. Office 2000 has a very very very good installation/management tool, one that I have not seen equaled before (not that one doesn't exist, I just haven't seen it personally). You get to choose which components to install, it checks for all dependancies and will fix things that end up broken, you can have part of the installation on CD part on disk and park on the network and it will all work pretty seemlessly, and you can keep everything updated and good to go from the internet. I really wish the RPM system could do all of that.
Of course Office was designed to work with the installer which is a big help there. I think that goes to show the people putting out a program are responsible for the install and setup of said program. Know the limitations of your distrobution medium, don't write shit that a majority of people can't use because they don't have some exclusive kernel hack or obscure/outdated/stupid library (that is unless your intent is for people not to be able to use it without these things). I remember back in the day of Windows 95 when people wanted to do graphics or animations in their apps they would just use Quicktime because it was well established and meant less work for them. The problem was that everyone used a different version of Quicktime and installing a program fucked everything up. The situation shined some light on the major drawback of the installation wizard for Windows, the lack of context logic which would let you keep your updated version of a dependancy and not fuck things up because of it and that programmers were being lax with their dependancy management. The article points out the same problem with RPM and how things are going now. I hope everyone learns their lesson and package systems manage whole systems well (not just a single program) and programmers make sure their shit works unexclusively.
I'm a loner Dottie, a Rebel.
Your list of functions is useful but it includes a great mixture of different types of things, and it's worth breaking them out:
- some that depend on Web-based, collaborative package reviews (which don't really exist yet and IMO are a big need for open source). This needs addressing, ideally using websites that have proper XML tagging so that programs can extract the reviews and search/analyse them more easily.
- some that depend on the package (e.g. help files or intro docs, and the ability to browse package docs before installing).
- some which are true package management issues, e.g. don't install packages that would require upgrades to libraries already in use. This is an example of policy - it would be helpful if a standard approach to such policies could be defined, then the various packaging tools could make sure they support this, and the GUIs could make it easy to specify this.
I think a lot of these issues are being addressed, but in a piecemeal fashion, e.g. Freshmeat.net is great on listing packages but not on reviews, various packaging GUIs may make it possible to more easily browse docs and specify more complex policies.
It might be useful to have a packaging framework initiative that tries to encourage various efforts in these areas and acts as a central point of information and even standards (e.g. standardised XML tags for reviews).
My main issue with packaging tools is that even with GUIs they require a lot of user expertise - first of all, where to find the RPM, then checking it's the latest version and compatible with your system, then which mirror to select for a fast download (a separate problem but one that should be automated, see the SPAND project).
Then there's the issue of managing or archiving the downloaded packages once installed. It would be useful if there was a log file of all installed packages + how they were installed, held in the archive directory, so that you could just back up this directory to get a fairly quick and dirty restore of this system (or to ease mirroring installs on other systems).
>One of the problems with RPM is that they arean't >always relocatable. The packager has to give you
:^)
:^)
>the option for that to work. Now I don't
>know whether or not that works with quake, but if
>you take enlightenment as an example, it isn't
>relocatable.
Sorry, I thought it was important to quote the whole thing.
This is exactly true. The thing is, RPM's powerful feature set is dependent upon the packager to implement features like this.
You've stumbled upon a debate that's been raging a while: how do you make a package manager that can put files in the filesystem in a relocatable way and still not break anything and everything? I personally vote for a re-work of Encap, but that's just me.
Stating on Slashdot that I like cheese since 1997.
1. "Windows uses shared libraries" But I don't think installation on Windows is too great either. They invented the term "dll hell".
2. "But glibc is huge!" I don't think he was talking about glibc or xlib or anything else you always get on a stock system. He's talking about libart and gnome libs and Qt: the files that are causing the problem! I don't see any reason why these cannot be static linked.
If we are worried about memory, add a hash encoding scheme for readonly pages so identical pages are in the same memory. This will result in probably more savings than shared libraries. If we are worried about disk space create a file system with the same type of hashing.
Also, what is wrong with source code? How about designing a "packaging" system that COMPILES the program. I believe users are willing to wait for the compilation, if only it was automatic.
The files for a package can all remain in a directory despite the problems with the Unix file system if you use symbolic links from the proper place to the package directory.
To install Joe's program, you need Bob's kernel hack, but for Bob's kernel hack, you've got to have Suzy's patches, but Suzy's patches only work with a year-old kernel, unless you get Mike's patches to Suzy's patches, but even then, those conflict with Jeff's drivers, which can be resolved only by installing Nancy's patches...
From http://www.spatula.net/proc/linux/index.src
Encap supplies that kind of functionality. The following example implies that you have a more-or-less properly packaged source tree (i.e. autoconf & buddies)
/usr/local/bin, /usr/local/lib, etc. When it comes time to uninstall the package, you simply remove the directory and run "encap", which removes the symlinks associated with the package.
:^)
./configure --prefix=/usr/local/encap/[packagename]
make; make install
encap
and encap makes symlinks to
It saves an incredible number of headackes and (you'll appreciate this, drsoran) a lot of *time.* Especially if you don't have a lot of itme to burn. (Sorry; couldn't resist a Dr. Soran joke
Stating on Slashdot that I like cheese since 1997.
Looks to me like everybody missed one: the POSIX package format. It has been in existance for quite a few years now and is used by various other OSes. There was even a Linux version (done by Unifix, the same people who did the POSIX certified distro).
It's been at least 2 years since I used the POSIX package management tools, but as I recall, it did all the dependancy stuff, pre/post install scripts, in-place upgrades etc. It even knew about architectures. Packages could be local files, on a tape device, read from a server and so on.
No doubt, it doesn't do everything you ever wanted, but I'm not aware of any readons why it would be a bad alternative to RPM/DPKG.
-- Steve
The original poster seemed to be implying that we'd run into compatibility problems by making additions to RPM. I provided a simple way to keep compatibility problems at a minimum. My post had absolutely nothing to do with compatibility between RPM and dpkg. Perhaps I should be the one telling *you* to say something useful.
Conectiva missed the whole point of APT. APT is not about automatic updates of the system. It's all about freedom to trim the system (/etc/apt/sources.list) so you can (i) use faster mirrors (ii) use new sources from third-party sites so third-party software can also benefit from APT.
Given the early record of Conectiva in trying to do a closed Linux, I wonder if you can expand their APTized RPT. I don't wonder, I'm certain that you can only use THEIR site. And their ftp sucks so bad that you can't resume downloads!
And one thing more: this ensures Conectiva users can only use Conectiva RPMs. (I doubt RedHat will use it, and have my reserves if other distros RPM users will use it also).
Cesar Cardoso can be found at cesar at zyakannazio dot eti dot br (or at least I believe so)
Well, although I've use Linux for long time, S/W management on Linux doesn't look as smooth as that of Mac or Windows.
For example, although there is no package management program on Mac, you always have feeling that you know what you installed, and where they are, etc. But on Linux, although you know that, but you feel that something is not perfect and you feels as if you miss something.
There are lots of programs are installed when you install Linux, but it's common that people don't know what are installed and what they are.
I think any package manager or Linux file/directory configuration should address it.
Isn't it strange that there is no "Installed S/W list" or something like that on Mac, but it's easier to track those on Mac?
( Windows has one. It's Add/Remove S/W control panel. )
And.. on Mac, you can safely remove and copy your apps freely. But on Windows or Linux you can't.
Especially on Windows. Mac S/W doesn't locate extension files on system folder except for when it's really necessary.
Windows is not at the level of Mac in that sense, but file management on Windows feels easier than that on Linux.
What is missing on Linux?
Hmm..
That's what remark lines are for, to index the source file.
My reason in saying that a modular setup is unstable is in the fact that the upgrading of one module at a time leads to instability from module incompatibility. For example, I installed a mod for Unreal Tournament (more modules for an already overmodularized game). I thought that it stank, so I uninstalled it. Next thing I know, the uninstaller removed a critical module inside a module, so I was forced to re-install the entire thing! That's why I hate modular setups; because of the christmas light factor: if one module goes dead, then the entire program goes kaput.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I don't know; maybe it's just me, but I think that packaging systems are just a workaround for the fact that UN*X-like filesystems weren't really meant for folks installing/uninstalling a bunch of crap all the time. UN*X machines seem to be designed to be kinda like a telephone: you use it, you occasionally have to make moderate changes to change with the times, but not much happens in the way of change.
:^) It'd be kinda nice if the *Linux community were that organized. Unfortunately, there's not that kind of organization; we're not as bad as *BSD but not as good as FreeBSD, if you know what I mean.
:^)
:^) The only reason I've been aware of the *BSD world lately is that I've been trying to build a set of standard BSD utils for Linux, mainly for shits & giggles. :^) (BTW if anyone is working on this and has any clues for me, let me know.)
I rather like FreeBSD's way of doing things; the fact that you can rebuild a system by issuing a single "make" just gives me goosebumps.
Still not sure? What I mean is that there's not one standard distro, like, say, call it FreeLinux. Have a standard committee (yeah, I know; people will be screaming "Debian!" and they can scream all they want.) and build *one* source tree.
The only thing I would change about the FreeBSD-style build is to allow for changes to the base without upsetting the main build. Perhaps have standard stuff like the kernel, libc, gcc, X11, etc. as part of the standard build and maintain things like KDE, GNOME, specific graphic support like Glide drivers, etc. separate. These should be separate in the sense that one could pull them out easily. How could that be done? Well, I'm partial to Encap, but that's just me.
Yeah, I think that's sad that only one comment was made on the new BSD packaging system, and an abusive one than that. Yeah, the folks that read Slashdot are kinda biased.
Stating on Slashdot that I like cheese since 1997.
I've never *ONCE* *EVER* had apt core-dump on me. Expecially since most of apt is shell scripts.
Debian's "must be free" policy is just fine. Debian also distributes "non-free" packages (not officially part of the distro, but still very easy to get at), if you want them.
--------
"I already have all the latest software."
I am SO for something like this! I have been a faithful Debian user for 3 years, but I work with RedHat, SuSE, etc. at work everyday. I've also had some decent experience with FreeBSD and the ports collection ROCKS!
I really like Debian's packaging and tools (yes the tools rock but the Packges and the system as a whole is what makes apt-get so neat) I also really like binary packages with simple default configs and dependency checking.
Ports has most of this already. If there was a way to adapt ports and source .debs I would be in heaven!
I have seriously considering porting ports to Linux, but currently don't have enough free time to spearhead such a movement.
If the BSD's standardize on the same ports... why not move it to linux and have that in common across ALL platforms. I'm sure that you could get it to check the dependencies of the existing package format so you don't needlessly compile unneeded things.
This woould also be a great way for commercial software makers to distribute their software too. make can handle binaries too.... just have the "make world" just do the binary install. All they would have to provide is a tarball of their ports directory.
Using make and some external utilities (dpkg and rpm for dependencies) can and DOES make for a very robust package management system.
"I actually use Encap on a Linux-Mandrake box(!) to keep track of what packages I've installed by source, rather than making my own RPMs."
Hey, now thats not a bad idea!
Well we aren't talking about RedHat here (it would be embarrasing for them to do this, and counterproductive as well - they designed RPM for the needs of the market they are going after, and it servest them fairly well) but Conectiva - a very different distribution designed for a different market. It is Conectiva that desires the apt functionality - RedHat does not. And yes, it would be a pain to switch over in midstream, but it would be equally a pain to try and hack RPM into doing things that it's designers consciously eschewed - AND THEN deal with the support nightmare created by using what amounts to a different architecture by the same name - i.e. other rpms will no longer work, but there will be no readily apparent clue to the users that they won't or why they won't.
When a fundamental decision was made in mistake, correcting it after is always a pain. Every package in the distribution will have to be remade either way. Compatibility with packages from other distributions will be broken either way..
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
No, no, no.
You've got it all wrong. Yeah, I know you're trolling. Ya got me. You got the bastard who's karma is permanently stuck at 5. So bite me.
How have you got it wrong? Well, I've watched people make comments about, say, *BSD in a discussion like this and get a (0, Offtopic) or a (-1, Troll) or something like that. Most of the time they're not. Why were they marked trolls? Because people like to rant enthusiastic with such witty comments like "Fuck you; we're talking about Linux not *BSD" and so on.
What's wrong with the attitude? THEY'RE NOT THINKING!!! It never occurs to them that they might learn something. Ever, say, taken a look at the FreeBSD build tree? BRILLIANT! It's so simple a trained monkey could build it from source. Will we learn from it? Heck no; it's FreeBSD. (NOTE: smarter people will.)
Putting the "I know I'll get modded down for this" usually ensures that the person reading the comment will stop and think before they start ranting, or, worse, the karma whores with new moderator status start knocking them down for thinking. (Bad person. Double plus ungood think!)
Stating on Slashdot that I like cheese since 1997.
Windiots don't like to use the keyboard. Click. Click. Click.
If Microsoft innovated an onscreen virtual keyboard, I bet Windiots would rather click on the keys with a mouse cursor, over using an archaic keyboard, 'cause those are only for DOS anyways.
Lars -
are a STAR!
This worked fantastically well.
Eternal thanks and gratitude.
--
Peter
Real men compile themselves.
What's really cool is that MS developer tools are quite happy with '/' instead of '\' in things like include paths, so there's no problems using CL.EXE from Cygwin bash.
Pity Sun's JDK can't do the same trick. Or gcc, for that matter.
Often the demoware writers will "hide" a registry key somewhere which they look for later, so that you can't do multiple demo installs (particularly for time-limited demos).
That's a designed-in feature, not a bug. You may not like it, but blame it on the application software, not on Windows. Ditto to your other arguments.
--
Sometimes it's best to just let stupid people be stupid.
Port lintian (Debian's implementation of the same thing). If you have a policy to work from, it wouldn't be that hard.
How dumb can that get? You would think thye would provide you with a UNIX tar ball? A UNIX Sys-V pkg file? Or even the old detested CPIO archive? NOPE! The only way to get RPM for systems without RPM, that is every UNIX system apart from Linux, is to get an RPM package with the binaries compiled for your platform or an rpm with the source.
Honnestly, I remember Linux as 40 diskettes install, way back when you compiled your own stuff and Linux wasn't that "pretentious" and quite open. Today I have the feeling Linux users don't have a clue about UNIX, just look at how un-portable some of the code is today.
Why bitch like an old WWI veteran? Cause it's Sys-V that still brings the moohla home for the employed sysadmin.
pkgtools are my choice. Anyone feeling for a port?
A few comments on remarks you made, in roughly the order that I encountered them:
1) Nobody here says they defend a person's freedom "to do what they wish without being harassed", regardless of what it is that they wish. People defend a person's freedom to do the things that they ought to be able to do, and that's usually the result of a trade-off between the rights of the do-er and the rights of the do-ee.
2) Your sexual *orientation* is not illegal, at least not in the U.S. If you're arrested, it's because of illegal acts you commit.
3) Don't even THINK about comparing yourself to a holocaust victim.
4) What technology would protect you from those who would harm you; who wishes to deny you said technology; and what do you mean by "harm" in this context?
5) Yes, the word "pedophile" was hijacked just the way the word "hacker" was. "Pedophile" means, literally, "lover of children", and without its current twisted connotations, would more aptly refer to those who truly love children, such as their parents and grandparents.
6) If the majority of pedophiles (current common connotation and usage, i.e. someone who desires sexual contact with children) have never done anything illegal with a child, it is because they have done the right thing and restrained themselves.
7) I don't know what you mean by "valid" in the context of "[my sexual orientation is] just as valid as homosexuality...". An "orientation" is neither moral nor immoral. It simply is. Behavior is a different story.
8) Nobody misuses the word "pedophile" to mean rapist or murderer. However, some pedophiles also happen to be rapists (which they can become simply by acting on their orientation) and murderers. What I find hypocritical is the fact that YOU are the one misusing the word "pedophile" to refer to someone such as yourself who, by your own admission, desires sexual contact with a child, when in fact the word should refer to someone who *truly* loves children and wants to protect them from people such as yourself who would engage in sexual behavior with them if they had their way. Your comments here are akin to those of a *cracker* who complains about the abuse of the term "hacker".
9) If you truly had a deep understanding of children, you would understand, as the rest of us do, that children lack the maturity, wisdom, and judgement required to give INFORMED CONSENT to engaging in various activities, such as sexual activity, and that an adult, any adult, has too strong an authoritative influence over a child, any child, for a sexual relationship to be legitimately construed as "consensual" in any meaningful sense of the word.
In conclusion, if you feel the urge to steal, but you refrain, then you can function in society. If you feel the urge to kill, but you refrain, then you can function in society. And if you feel the urge to have sexual relations with children, but you refrain, then you can function in society. But if someone can't resist the urge to have sex with children, then perhaps that person should take Dennis Miller's advice and commit suicide, or, as he put it, "just lean into the strike zone, and take one for the team".
The package in question is "mail-transport-agent". There is a section of the Debian Policy Manual which defines the features expected in an MTA.
/bin/csh
/usr/bin/wish
If the feature you seek is within that policy definition of an MTA, then you can depend upon "mail-transport-agent" with confidence. If not, then you need to determine which other package(s) (real or virtual) satisfy your needs.
If this hypothetical need is something that more than one package requires, then defining a new virtual package, defined in terms of that need, provides pretty much what you request.
It would be entirely possible to break the features covered by mail-transport-agent into a whole list of feature-based virtual packages, but from expeience (in Debian) is seems that that is not in fact required.
There are one or two very specific virtual packages in Debian, for example:
c-shell - Anything providing a suitable
wish - Anything that provides
which are effectively what you are calling features. Note, these are more than file dependancies, because they carry with them the requirement that the functionality of the file be "standard"
Debian: GNU/Linux done the Linux way
The issue here is that your uninstaller is broken. If you were using good packaging system (such as dpkg or RPM), this would not be an issue, because the "critical module" would not have been deleted. If you don't mind me asking, what packaging system were you using?
And since when do Christmas lights break if one light dies?
In Debian, DFSG-freeness isn't connected to the filesystem structure at all. Non-free packages (say, Netscape) are still placed in /usr, because the Debian policy applies to free and non-free packages alike.
The policy is what makes Debian so solid, mostly adhering to the principle of least surprise. The process is open and evolving, too.
"begin browsing the documentation for a package before approving a full installation?
again, you're asking the package manager to do things that just don't make sense. Why not read up on the software, then install it? Or just install it, and if it's no use to you, do an 'rpm -e'."
The difference here is User Centric versus System Centric computing. It's possible to do the things you are asking, but it's also possible for the package manager to do some of them. It's not unreasonable to ask for a package manager to provide the tools you would want when looking at a package.
Why not have the manager open the man file? Link to the webpage? Provide an overview? Nothing here is impossible, but you make it sound silly for this guy to even ask for these things.
...everyone just use tar.gz? I mean, it's not that hard, just type
$tar xzvf MyProgram.tar.gz
IT'S NOT THAT HARD, PEOPLE!
Friends don't let friends use multiple inheritance.
All RPM packages shipped by redhat or any distributor (AFAIK) are **designed** to be noninteractive, so that the vendor's installer can load them up as part of a nice graphical installation script.
And I think that's right. I think that if there is any complicated configuration procedure, it should be made part of the application's internal configuration screen. Package installation and uninstallation has to be as simple as possible, no more complicated then copying a bunch of files, and maybe running a simple script, or two. That's it.
I don't want to turn Linux in 'doze, where you have to screw around with a bunch of convoluted questions during installation, then, after it's installed and you realize that you've fscked up, you have to go back and reinstall the bloody thing. No thanks.
---
I must say that I have wanted to see a linux version of the *BSD ports tree. I prefer to work with source rather than precompiled binaries. I just think that, for me anyway, binary packaging systems are to easy to break. You can easilly add things to a system not going through the packaging system that will screw up the entire packaging system because they don't check if things actually exist on a system just if they have been installed with a package.
What's nasty (or cumbersome) about it? Simple and elegant, I would have called it. The only awkward thing can be getting the makefiles to do what they are told - and it's hardly stow's fault if people write kludged makefiles.
As I've said before, OOPS! I don't use perl, I just randomly see it being used around me. I'm a C/C++ person, so don't bug me with your little interpreted string parsers. feh! ;)
-Leo
tell the system to apply only security or high-priority fixes?
ask for only packages targeted at beginners?
These two problems (and many more not mentioned) can be addressed by having subdistributions. The could be a subdistribution of Debian that never changes except security fixes. There could be a subdistribution that only contains packages for beginners.
What you are asking for is many different perspectives on how to organize software collections, and this can be done by a multi-tiered distribution system with many middlemen. I finished a thesis on this subject in 1997. Just read chapters 1,2, and 5 -- the rest talks about a specific design/implementation to address the problem that was, um, lacking.
I'm sorry. I read your post again, and I'm not exactly sure what I was thinking.
--------
"I already have all the latest software."
Right.
And for the most part, getting those depedencies resolved is *easy and fast*.
With rpm, it's fairly simple.
With apt + deb, it's dead easy. (not judging either.)
With windows? Ha.
Linux is hard to upgrade??
Which distro do you mean?
Redhat isn't too hard, although it can be a bit messy.
Slackware is a bitch.
Debian is dead easy.
Each has it's flaws and strengths.
Last time i used a redhat box, rm was aliased to rm -i or some shit like that so it asked you if you really wanted to delete the file(s), just like the default setting for deleting stuff to the recycle bin in Microsoft Windows. So you couldn't blast stuff away without actually knowing you were doing it. Of course, thats what happens when you use root as your user account ...
Lars -
> patching anyone??
.srpm and .src.deb were made for) - you're dead, having as many chances for the binary to run as with dd if=/dev/random of=binary. Look at the kernel: yes, a patch is smaller than a kernel - but all the patches required to transform an 2.2.5 (shipped with an imaginary distro) to 2.2.17 or the patches to get from 2.2 to 2.4 are WAY WAY WAY bigger put together than the kernel itself. And no, having a zilion patches for upgrading ANY verion to ANY version is not a good ideea for the ftp servers's owners.
NOOOOO ! God forbid ! If you recompile a binary for performance'n'stuff (that's why
--
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
I prefer the term "Boofing"... I "boof" the box every 6-12 months... People where I used to work thought I was crazy, but then they always commented on how much faster my comptuer was...
What really amazes me is how installing software on windows bogs it down, without it even being loaded. Just having something like MS-Office eating a Gig of HD space isn't that bad, I've got just as many MP3s (legal, not being shared), and they don't cause problems. It's just the 5-10MB of data that was just thunked into the damn registry. Why do they need to register 200+ classes?
I like my Debian boxes. So nice to install, so fast, I set them up, they run, and since I don't worry about public attacks (firewalled heavily by other people), I can pretty much just let them sit and serve me files.
Why is it that people assume that sex is inherently harmful? I agree that harm (such as STD's and unwanted pregnancy) can be a result of sex, but in that case wouldn't it be better if children gained experience in it with adults rather than learning by trial-and-error from eachother?
I think that RPM needs to be more like InstallShield for Windows; letting you pick the directory while it puts the system files where they're supposed to be. Enough of this "non-intervention" installation package system, it's time for the users to demand control over their own files. This right has gone unenforced for far too long.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
No problem. :-)
Actually it is rpm -ql package_name for listing all installed files, and rpm -qd package_name for documentation files.
Rohan
Rohan
Am I the only one who thinks that the ability to know exactly what is being installed on my system at any given time is a good thing? Don't get me wrong, I'm all for functionality, and ease of use when it comes to up-dating packages, but one of the reasons that I use linux is because I got sick of things like Explorer's auto-update garbage. I have only been using linux for a few months, and I've learned a lot from rpm's "failed dependencies". Even though these install trials a pain when they're happening, I like them because they force me to crack open a man page or a howto and figure out what exactly is going wrong and how exactly I (newbie or otherwise) can solve the problem. Invariably, the problem is solved, not by some automagic process, but by my learning something new. I like that. I think that it's time the linux community stop wasting time on frills and spend more time on what they do best: building a stable OS with good, solid and secure code.
Or how about a binary incremental (patch) upgrade? I know that's not easy, but it would be really nice.
----
Celebrate the finer things in life
Umm, Solaris pkgadd, pkginfo, pkgrm utils suck. Ever wonder what package filex belongs to? How about the amount of Solaris packages? (Don't say www.sunfreeware.com either, those packages are old and there isn't many of them) The *BSD ports method has some cool features, but how about upgrades? How about makefiles that don't work? How is the ports collection any more flexible than say RPM? Or for that matter better implemented? I have used the *BSD ports collection for about a year and find them to be lacking in features/robustness compared to Debian's packaging system. I have had more than a few *BSD ports fail because "all of the ports haven't been converted to the new method/system (I am using 4.0 STABLE)". Having multiple QT libraries is a real pain, etc.
tar zxf tarball.tgz
./configure --prefix=/tmp/tarball /tmp/tarball
cd tarball
test test test
ick
rm -rf
:wq
I used RedHat for about 4 years, and recently switched to Debian mostly because of dpkg.
I'm sorry, but dpkg as a package management tool is so superior to rpm, that it was like going from Windows to Linux again. Yes, Windows is nice if you've never experienced anything else, but once you tried something better, you really don't understand how you could have been so blind.
Redhat 5.x used rpm 2.x. Redhat 6.x uses rpm 3.x. Redhat 7 will be using rpm 4.0. Guess what, each major version of rpm is incompatible with the previous version. This coupled with the fact that I have never successfully upgraded a RedHat system (I usually either reinstall or do a manual update, as in go through my list of rpms and do a rpm -Uvh package.rpm from the CD, making sure I don't upgrade packages that are newer than those on the CD).
In Debian, I changed my sources.list and did a 'apt-get dist-upgrade'.
apt-get install will ask stop and ask for configuration issues. I have yet to find a rpm package that did that.
rpm -bb -clean --rmsource package.spec is supposed to compile, create rpm, and remove the source and spec file according to the docs. It never removed the spec file in rpm v3.x
lets say I wanted to remove xanim. I have aktion installed dependent on xanim.
In dpkg, I would do:
apt-get remove xanim
Since aktion depends on xanim, dpkg will ask if I want to remove xanim to and *do* it in the same step.
rpm -e xanim
Failes because aktion (if the dependency is even set up) has something dependent on it. You then have to do a rpm -e for each dependent.
Quite frankly, having used both, I just like dpkg much better, I wish all Linux distributions would just bite the bullet and standardize on it. Heck, if each major version of rpm is uncompatible with the previous version, it's no harder to go over to dpkg than to go to the new rpm (just write a tool that convert the rpm database to dpkg's text based database).
Je ne parle pas francais.
Nice article... cept i think the comments were more interesting than the article itself... I use rpm alot and it really annoys me sometimes..i do agree with the fact that configuration should be based in the program itself and for there to be a default config and be able to reconfig within the program... packet management is exactly that managing packages and making sure their in the right place and all dependencies are accounted for...not to be messing around with config files within the actual programs i think thats beyond the scope and function of packet management... i sure would like it if someone would do something about the dependency problems that crop up when ur installing packages...at least link us to where we can find the dependencies heh... All in all rpm and apt are a god send...especially for newbies but the can really be a pain in the neck sometimes...and the fact that when u wanna update packages u have to download the entire binary again maybe slightly bigger...patching anyone??
"Thats the way the cookie gets totally stomped on!"
dpkg is pretty decentralized (as much as RPM is, anyway). Ever edited /etc/apt/sources.list?
--------
"I already have all the latest software."
As far as operability on a completely mucked system, I have on occasion relied on the (nice) fact that a .deb is really just an 'ar' archive.
/tmp/package-extract /tmp/package-extract /path/to/archive/like/var/cache/apt/archives/file. deb / /tmp/package-extract/data.tar.gz
Say I wanted to forcefully reinstall a package, not caring about the database and such, just get me my program back:
# mkdir
# cd
# ar x
# cd
# tar zxvf
control.tar.gz in the same archive contains all the scripts and such, so you can even run those manually if you need to. And the package database is (for better or for worse) ASCII anyways, so even if you only can get 'ed' working, you can mess around with it anyway.
I used Red Hat and rpm for about 6 months. Then I discovered Debian, and liked it a lot better, largely because of its package management. rpm can conceivably do a lot of the things Debian packages can do, but Debian has it here, now. As for the multiple versions of packages advantage claimed by RPM users, I should note that Debian packages (most often libraries) can have a version appended to the end of the name, and many do. libc5 and libc6 are quite plainly two distinct packages as far as the package management system is concerned, even though they provide much the same functionality. This applies similarly with other packages whose maintainer(s) have judged that having two or more versions of that specific package on a system is useful.
As for the file dependencies, I can see how that is a good idea (you execute, link to, copy, move, etc. files, not packages), but as the article mentions, it expands the dependency tree quite a bit, and I have personally had no trouble with Debian's package-oriented package management (if you depend on one file in a package, you likely depend on, or could somehow benefit from, the rest of those files, and they would get installed anyway when you installed the package). Need the GNOME headers? apt-get install libgnome-dev. Not brain surgery, and beats Windows's install-remove system by a landslide. Mac uninstallers can leave things behind also, but being able to just throw away the app's folder, preferences, and in some cases control panel and extension, is a very nice idea IMHO, but it doesn't scale well. I'd like to see what OS X does. (pssst, anybody got the CD? Can you post an ISO?)
Hate to say it, but as we expect more and more from our packaging mechanisms, we have to lean more towards a central repository, or "registry" if you can stand it. Not that that "registry" has to be in some funky proprietary format, but there needs to be some central place where apps and configuration utilities can get some info about their installation, configuration, and removal. I mean, the passwd file itself serves as a "registry" of user account info that other applications are dependent upon. This is fine.
I think there is some project out there to standardize configuration files. One of the suggestions was XML. While I think for very simple configurations XML is going overboard, I do think some standardization needs to be made. When I configure an application, I don't want to have to learn a new configuration format. And I would like all installation and removal to be done in a uniform seamless manner for all applications. So, in short, I think we need standardization on these issues. Since *everybody* has to install and remove stuff on different systems at some point, "choice" is not a perfect alibi here.
It's 10 PM. Do you know if you're un-American?
If I have the source code for a package I am more likely to install it with
make
make install
I actually install into /usr/local/pkg/package_name-version-number, rather than /usr/local/stow/... as I sometimes use lndir or even just ln manually instead, thus the independent directory name. I sometimes also keep multiple versions of software around with only one set of symbolic links in /usr/local, just in case I have needed to revert to an old version, which I have had to do once or twice!
Stow doesn't work that well for pre-compiled binary packages that have odd directory names and documentation files in the main directory.
Sure, you can remove them, rename them etc, but I like to keep /usr/local as clean as possible.
Just my addition to the subject of package installation.
Rohan
Rohan
I started out on a debian machine(well aside from that short encounter with mandrake..) and Apt is a kick ass package management system. And with aptitude it is even better. I admit I only really use aptitude to find out what packages are available, but it is a step in the right direction. I manage Redhat boxes at work and rpm is difficult to deal with in comparison to apt. I can't easily query a trusted source of packages and it is hard to understand all the commands. APT is it..
-b
All this piece really says is that developers and packagers need to do a better job of keeping dependancy lists and such in good order. RPM has some great features, and Redhat has made a lot of progress on it feature wise - version 3 is far better than previous versions, and includes the pre and post install script capability as described in article.
I see this as less of a problem with RPM and more of a problem with developers. This is not to say that RPM couldn't be improved - it could run ldd or some such library dependancy program on binaries to help out the situation, or some modified version of strace that checks to see which files it accesses, but in the end it falls to the developer and packager to make sure that the package is works correctly and lacks dependancy problems.
BBK
How about just making a rpm-lint program to check to make sure your package follows the suggested policies? If building a package it that hard, write a front-end to make it easier.
"The axiom 'An honest man has nothing to fear from the police'
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
Consider yourself enlightened.
--
Information wants to be beer, or something like that.
In the brief time that I've been using *nix... I have downloaded & installed 2 rpms successfully. I have *never* had a problem with a gnu-style ./configure;make;make install. Not once. I don't really understand why package managers are usefull to anyone at all.
--
There are no trails. There are no trees out here.
The problem with all of the library dependencies isn't really the packaging system, it's the fact that packages are distributed in binary format. That has disadvantages..
Dependences cannot be expressed easily. (Like based on the compiler or another library.. There's a reason that every library number increases whenever a new version of glibc comes out.)
Someone tries to install two packages that require the same library, but different versions, at the same time.. BOOM.
Maybe Bernstein had it right.. Binary distribution sucks.. Use the source.. This is (IMHO) How freebsd gets around the problem.. By forcing you to compile every package as you install it.. This isn't QUITE so bad for installing a couple individual packages.
The suggested policies may be a Good Thing (tm), but they raise the barriers-to-package a lot higher.
RPM is fine. I think anyone with half a brain can read a readme file and be told to run a configure script or something (post-install).
And running /etc/rc.d/init.d/servicename stop is NOT THAT HARD! People would do well to figure out how their linux system works!!
And you can compare versions of config files yourself for crying out loud.
I think RPM is in fact overkill for what it does, and there's no need to bloat it up and make it even MORE brain-dead friendly!!
Personally this move towards dumbing down computers (it all started with the damn MAC, then windows... and now it's happening to Unix) makes me sick. I don't like every tom dick and harry out there with 1/5 of a brain reaping the benefits of our hard work as developers and not appreciating what goes into making it all work so smoothly. Personally I think the more we make them suffer, the more they will appreciate us as developers!!
Also, I think that one shouldn't underestimate the intelligence and capabilities of users. I think we should look to challenging our users and educating them rather than dumbing down everything to the point where it is no longer fun. Detail is a good thing!
They probly have in Win98/2000 too. It's part of their "accesibility options" for disabled people.
Perl is usually in /usr/bin or /usr/local/bin. I don't think anyone in their right mind would put it in /usr/sbin.
-cc
I don't understand why someone doesn't just write the damn thing. The rpmfind database seems to have all the necessary information, why doesn't someone just write the wrapper that will make it work like this:
#rpm-get windowmaker update
Installed version of windowmaker is 0.58
Found windowmaker on rpmfind.net.
Latest version of windowmaker on rpmfind.net is 0.62
Update? Y
Retrieving windowmaker-0.62-2.i386.rpm.......
Needs libpng >= 1.03. You have libpng version 1.02 installed.
Update libpng? Y
Found libpng on rpmfind.net.
Latest version of libpng on rpmfind.net is 1.02.
Found libpng on sunsite.unc.edu.
Latest version of libpng on sunsite.unc.edu is 1.03.
Retrieving libpng-1.03.i386.rpm......
Package gimp needs libpng.s0.0 from libpng version 1.02. [F]orce upgrade of libpng, [i]nstall new over old, or [a]bort? I
Installing libpng..........
Updating windowmaker........
Keep local copy of RPMs? N
Deleting libpng-1.03.i386.rpm.
Deleting windowmaker-0.62-2.i386.rpm.
Finished.
That's what I would like to see. I know, "code it yourself."
- Have a picture
When it comes to limitations, both packages share them. Both of them only specify dependencies by name, rather than by function. That makes it impossible to assure that a particular installation is actually working or how to fix it if it isn't.
Neither of them requires test cases to test an installation.
And both systems allow arbitrary install/deinstall scripts, making it impossible to write general tools that analyze automatically what happens during package install/deinstall.
Rather than spending time making one more like the other, we should stick with what we have and worry about the next generation packaging tool, which will probably have to be started from scratch.
I've used apt and rpm with autoRPM. Apt wins hands down in my book.
Apt is absolutely perfectly suited to the task at hand, which is getting everything you need together to install a particular piece of software. The task flows completely smoothly with never a hitch.
RPM is more of a hackish tool. There's always some trial and error. There's nothing wrong with this in general, other than I usually have other fish to fry.
Example: the other day we had a cert advisory story related to a vulnerability in wu-ftpd. If I were on a debian system I'd have that sucker set up to be fixed in about a minute and very shortly thereafter all would have been made well as I went on to do other things. Instead I spent a nice Sunday afternoon making repeated trips rpmfind.net. RPM fans who think I'm a moron are welcome to point out that I should have used the --do-it-intelligently-this-time switch. My parents installed me with the --i-can-take-it option. I'll fully admit I'm lazy. I want my package management system to take the objective I handle and take care of all the details, such as traversing the dependency tree, fetching all the needed files, verifying their cryptographic signatures, installing them and configuring them, while I selfishly take all the credit.
RPM fans are always saying "you need to learn more about RPM". Fair enough, but what's sauce for the goose is sauce for the gander. You need to learn more about apt.
I'd be interested in hearing from others who've tried both.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I'm sure that all of you have your own little habits and quirks; just keep in mind that I won't criticize you excessively on them, as you did mine.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
...except if you use installwatch (search for it on freshmeat). I've been doing all my installs on Slackware from source via installwatch for about a year now, and I love it. Uninstalling is a breeze! No more old versions around, etc. The Slackware-specific version is at Linuxmafia.
I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
I think one of the biggest disadvantages when using rpm is the lack of pure source distributions, that is, tarballs containing only a Makefile and some source files.
Those are the one that screw my system up. Sure, rpm -ta works but only when the tarball supports it.
Get installwatch from freshmeat. With it, you can get a tarball, compile, then let installwatch supervise the make install and write a log file - then a helper app (inst2rpm for rpm-based distros, inst2slack for Slackware) parses the log file and updates your package database accordingly. Works really fine.
I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
That's exactly my point. Your suggestion for how to implement this in the package manager means you turn the package manager into a web browser. Either way it's out of scope.
----------------------------
These guys are making a fundamental mistake. What they want is to make .rpm act like .deb. This is not going to happen in any meaningful way. .RPM and .deb are the result of fundamentally different design philosophies.
Yes, it is possible to make apt work with .rpms - but this will ONLY work satisfactorily with .rpms that are written with this in mind. The reasons given for using .rpm instead of .deb here basically boil down to there being more .rpms and more people using .rpm - but since all new .rpms will have to be produced to work with this system anyway, this is a false advantage. The installed base, the already existing library of .rpms, are going to be useless to this project in any case.
Obviously what they should do is just use .deb. The pre-existing base for .deb may be smaller than for .rpm, but it's infinitely larger than the pre-existing base of .rpms that contain the information needed to make this work, because that set doesn't exist at all.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I wish somebody would do something. I'm sick and tired of chasing dependencies all over the map. By the time you've downloaded the program and then the dependencies you can blow off the day. There's gotta be a better way.
maybe i said that because, *gasp*, i really did expect that mentioning FreeBSD as a valuable source of potential design information for Linux would cross religious barriers, and get me marked as flamebait.
/. community. The answers, in case you missed them, are both negative. And that's *really* common, especially among the karma whores who play the /. game very well, as long as the goal isn't the disemmination of useful information or the creation of interesting dialogue. I'm referring instead to the people who think that a goatse.cx or rotten.com link is the coolest thing on the planet.
Impossible you think? Then look at the maturity which exudes from your reply to my message, and think about what you've added to the
----------------------------
After using apt for the first time, I've been a steadfast Debian whore. Nothing beats 'apt-get update; apt-get upgrade' for saving a day's worth of effort poking around rpmfind.org for libraries or dependent packages.
Just the fact that I can do this out of the box in a Debian-based installation (you *could* set up autorpm & co. to do all this, with some effort) convinces me to use apt.
-another debian user-
------------------
"We can categorically state that we have not released man-eating badgers into the area." - Major Mike Shearer, UK
Well, it might be close to impossible to _you_, but some people know to use rpmfind and rpmfind.net and gnorpm and whatever tool you like to do it. And I don't believe apt-get is going to find my .deb I rolled out just a hour ago. It's obviously one tool for one distribution with one central repository. Once you go out of this repository (and gnucash is obviously out of the RedHat) into the fields of wild - I doubt apt-get could be much of help to you, without strong effort of the packager.
-- Si hoc legere scis nimium eruditionis habes.
Keep PATH short. It's safer. Ever heard of the old trojan trick of placing a script called ls in one of the dirs in someones PATH?
You make the mistake of thinking you can educate the fundamental stupidity out of people. You can't.
I'm at work. I could be monitored any time.
Links like that are diabolical.
You make the mistake of thinking you can educate the fundamental stupidity out of people. You can't.
RPM's got its flaws--in particular the bloat of its cross-dependency database once a system's gone through a few big waves up upgrades. But Mr. Matsuoka--and Mr. Covey--show themselves to be surprisingly ignorant of RPM's capabilities.
What set off little bells in my head was his contention that RPM can only update files and doesn't run pre- and post-install scripts and can't prompt users for parameters and install options for the packages in question.
This is just plain wrong. An RPM can contain and run both pre- and post- scripts both during install and uninstall operations. Plenty of RPM packages containing shared libraries, for example, silently run an ldconfig after installation. RPMs of things like mysql and postgres often do a lot more--initializing a database, setting up default db users and, yes, prompting for things. If his SMTP MTA packages don't prompt for anything, that's the packager's fault. Hopefully Mr. Matsuoka's job at Connectiva isn't as lead packager for their distro.
It would be nice to see both apt and RPM adopt a rich XML-based standard for expressing prompts, defaults and so forth for interactive installers, along with a way to express what prompts can be silenced and with what effect, so that text, widget-independent GUI, and web-based (among others) interfaces to interactive installation can be built without breaking anything. But this wasn't Mr. Matsuoka's complaint. He seems to think RPM's can't be made to prompt users or execute scripts.
As for Mr. Matsuoka's other contention, that RPM needs changes in order to allow smooth auto-updating of packages, this too shows inexperience. I'm sure users of, say, Helix-Update, RedHat's Priority Update tool, and for that matter the fully-automated silent autoRPM utility would be surprised to hear RPM lacks such functionality. That he doesn't know this is kind-of-sort-of excusable, since it's not covered in the books and documentation for RPM. Not so the pre/post install script stuff. That's in the docs.
Well, I dunno. Just seems like a lack of polishing to me, but this is of course just my opinion. At least on my system, it takes forever to 'stow -D '. In the time it took to unstow a librep-devel package I had installed, I had written a script that would find all the files in the /usr/stow/librep-devel-<version> directory, and remove them one by one. It didn't check to make sure that they were Stow's files, but it tells you something anyways.
:) Ya can all check out my more in-depth thoughts at http://dharris.twu.net once I get it finished.
A few other little things, like one-step unstow/removing. The fact that it relies on the user's current directory, and on the directory Stow is installed in(for default options, anyways).
:) Anyways, I like the concept!
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
i'd like to make a little note in the defense of RPM's. I like 'em. I don't use 'em much, maybe thats why i find RPM so appealing.
;-)
When you're installing an application for linux, i am of the opinion that it's best to do it from source. The idea of pre-compiled binaries just doesn't sit well with me for quite a number of reasons. Foremost, i don't like the idea that i'm using a binary build on someone else's box. And i certainly don't like the fact that i don't have the source sitting in front of me to hack, if i'm bored, or to just peer into, etc. (pls no posts on src.rpm)
RPM's, i feel, are great for the little utils. Miscellaneous files that i need for x without wanting to download and compile those binaries on my own. I just download an RPM and whabam! it's installed. Dependency problems? --nodeps. Won't install for some other reason? --force.
Maybe there are issues to be addressed if you want RPM to become your standard installer for absolutely everything. Yes, Forest Gump needs something more powerful. My question is simply why argue about RPM or apt when you've got source?
It's like arguing whether you'd like to buy a pinto or a ugo when you can get a porsche for free. (some assembly required
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
I love the acronym! PMS. Yeah, that sells. When I saw the subject header I thought it was going to be a funny post.
You make the mistake of thinking you can educate the fundamental stupidity out of people. You can't.
15+ hours if done all at once....5 minutes a day if done daily.
(+1 Funny) only if I laugh out loud.
Windows allowing apps to write all over the registry without my knowledge is a feature?
Windows is designed to bring the desktop to the masses. It therefore will hide everything that might be complicated. And they hide it well. So Windows will do a lot that you will not know about, like maybe sending data to Microsoft about your box. This shouldn't worry you because "[They] Do Know What Is Good For You And You Do Not!!!"
That's why I like linux and thats why I uses tarballs. It's my box, so if it's messed up, then it should be my own fault, not the fault of me not understanding some feature.
---
---
"Multiple exclamation marks are a sure sign of a sick mind." (Terry Pratchett)
deb is not centralized at all, only for convenience.
.deb
.rpm and .deb suck, it' ssyanig that rpm has a few features missing that make it fundamentally difficult to integrate it with apt. IT also points out weakenss in .deb. RPM does more, but is missing a few things that enable this tight form of system management.
apt typically uses between 2 and 20 different sites to fetch files from. Dependencies are not centrally stored, but contained within each
apt keeps a chache of everything available, and takes care of resolving dependencies.
so the typical behavior is 'apt-get update' (to update the cache' then apt-get upgrade (to check for newer versions of installed packages) or apt-get install package (to install a package) or apt-cache search string (to search the cache for a string)
BTW.. the original article at freshmeat is about exactly this.. it's not saying that
Simple. You can't make a GPL version of the Conectiva distro. They install StarOffice 5 (which is NOT GPL) as a default with the distro.
While ago, Bruno "Buick" Collovini, a famous Brazilian Linuxer, asked the people from a LUG (LUGs in Brazil are all become Conectiva money-free propaganda commitees) if a GPL disk can be made if the SO 5 was pulled. Nobody even answered if the installation was functional without the SO 5.
And more: a guy started to sell Conectiva disks, a mirror of their ftp. He suffered so much pressure from Conectiva and their gang that he had to pull out.
So: you MUST buy full Conectiva boxes to test their RPM.
You've been warned.
Cesar Cardoso can be found at cesar at zyakannazio dot eti dot br (or at least I believe so)
A feature I would like to see in RPM.
Is the ability to install tar balls!
Then it would be easier to install and remove experimental software.
If you don't like to change an operating system much at all, what are you doing trying to install programs to irregular locations? ;)
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
I have used RPM (Redhat for 3 years & Mandrake for a while) and now use Debian (for one year now). I guess my question is this: Would not it scare the RPM based distros to go with DEB, when it would be easier to only install a distribution 1 time. I mean their has to be something to the fact that each time I walk into Best Buy or Comp-usa, I notice a new point release of Redhat, Mandrake, Caldera, or Suse...I think apt-get update;apt-get dist-upgrade would just rain on that parade.
What do you think?
(+1 Funny) only if I laugh out loud.
The information is there. When I do an upgrade in Debian, it checks the config files. If a file has been changed from outside the package management system, I get:
Setting up ssh (2.2.0p1-1)Configuration file `/etc/ssh/sshd_config'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?
Picking option D gives me a context diff run though the default system pager (normally 'less'). Option Z gives you a shell and you're free to do whatever you want. The new file is in <old file name>.dpkg-new
--Phil (No, dpkg isn't perfect, but it is really nice.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
granted there are occasions where compiling is the only solution however why rebuild the wheel if goodyear's wheels are perfectly fine?
this comment seems to come from a user that has far to much time on his hands.
rev
ps. linux torvalds (afaik) uses redhat, want to tell him to stop leeching like a BBS luser?
error: package Mesa-3.2-1.src.rpm is not installed
[root@habernero src]# rpm -i Mesa-3.2-1.src.rpm
error: package Mesa-3.2-1.src.rpm is already installed
When you're doing rpm -e, you don't type the .rpm; you're uninstalling a package not a .rpm file.
While Red Hat Linux is far from a perfect distribution, it's intellectually dishonest to knock its tools when you clearly haven't read their documentation carefully enough.
(Although, on the other hand, it could be a reason to bag rpm's poor documentation, and the documentation on Red Hat in general. Have a look at /usr/doc/ and cry at its uselessness.)
You're a suburbanite.
On debian-changes, I see that uploads have a priority. Say I want only high-priority upgrades. (For that matter, why don't I see this priority anywhere in the installer or the package? What's the point of dropping useful information?)
Why are you running unstable, if you want to only risk installing critical updates?
I've been following unstable, and my system is happy now, but I just got some important work to do. I don't want to take any chances for the next week, unless they're security upgrades (or dependencies thereof).
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
And where is the old original config file? You have soooo much more information to work with if you have that. In my opinion, you can't do a proper merge without all three files (mine, older, and yours in diff3 terminology).
No, dpkg isn't perfect, but it is really nice.
I agree with that :-)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Ask any debian user why they use it, and one of the first 3 things theyll say (and more than likely the first) is ease of update.
so why keep rpm? because so many of us are familiar with it? I hope not. If that were the case we should all be using windows. I really see no valid reason to continue using rpm. Thats my 2 cents
Maxie Z
You're dead-on, and I haven't given a coherent argument for why it should be in rpm. Some other day :-)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Hey, cool, I'll do this once I start tracking unstable again. (I maintain machines that are still on slink, and I promised myself that I'd keep my machine on potato until all the others are upgraded!)
Thanks for the tip.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Posted by polar_bear:
While the folks who are doing the Linux Standard
Base Project are working on everything else,
perhaps they could provide a spec for LPM - a
Linux Package Manager - something that provides
interoperability with RPM / DEBs and eventually
replaces both.
I have five boxen at home - one runs SuSE, one
Mandrake-Linux, one Storm Firewall and the other
two are Slackware. Personally, I still prefer
to build from source tgzs - because I don't
really care 100% for either package manager.
Ah well - nothing is perfect and both formats
will only improve with time.
- ask why a new version of a package was released?
- see a list of changes between old and new versions?
- tell the system to apply only security or high-priority fixes?
- tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?
- tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?
- ask for packages that will help me convert GIF files to PNG?
- ask for only packages targeted at beginners?
- ask for only well-integrated, well-tested packages?
- get reviews of a package?
- find out how to get started using a package?
- begin browsing the documentation for a package before approving a full installation?
- have some help in configuration updates?
This is an abbreviated list, but I've wished for some variant of each many times.Note I acknowledge that these are hard problems. I don't expect them to get implemented overnight. The problem is, I don't see anyone even trying. (Possibly Helix Code, it's too soon to be sure; at any rate, they will need the help of the distribution maintainers to go all the way.) Someone could make a great contribution by seriously studying what users need to take control of their systems and designing a solution, not just looking for the next hack.
I use Debian personally. I think dpkg+apt has more cool hacks than rpm+autorpm (or whatever), but I don't think it's significantly further in the big picture. I do think it has more possibilities, given its philosophy and development community.
Finally, I know some moron will jump up saying that rpm wasn't meant to do all this, and its developers intentionally limit its scope. I don't care whether rpm solves the problem, or a system build around rpm solves it; I do care that the problem isn't being addressed.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
apt-get update
apt-get upgrade
and have the machine automagically be brought up to date. Also, the dependancy system is much more powerful, and it enables the sysadmin to add packages easily at a later date (RPM does not have an easy method of [re,de]selection like dselect). If i use apt-get install blurglator it will always install the packages it depends on without help from the sysadmin.
isomerica.net | Foonetic IRC
Is something more akin to the *BSD ports collection in Linux, rather than deb or rpm. I can't think of the last time I actually used either deb or rpm on a Linux box, it's usually easier to get source and compile rather than find a up-to-date package in either format. OTOH, using a BSDish box is usually simply cd /usr/ports/<class>/<program>; make && make install to install the most recent stable version.
This
I wish I had more time to learn how to program, and then actually program something. Many of you will be familiar with GNU Stow, and maybe even some of you had tried it. Well, I have. It's pretty nasty. While it works, it is cumbersome. But, I strongly think they've got the right idea.
/usr/local/stow/Quake2-version), and then it makes symbolic links, recursively, from the installation directory to the system directories. ie: /usr/local/stow/Quake2-version/bin/quake2 is linked to /usr/bin/quake2.
/usr/local/stow/Quake2-version'. To see what what package owned /usr/bin/quake2, I'd just need to do 'ls -l /usr/bin/quake2'.
/usr/local/stow/Quake2-version/), describing some things. Files named things like Requirements, Provisions, PackageInfo, PackageConfig.
/bin/ls) if the package required individual files, and package-dependancies(ie: fileutils-4.0).
;) To be honest, I don't think any new package management system will succeed unless it has compatibility layers for RPM and APT. Both on the shared-library leve, and on the command-line level.
For those of you not familiar with GNU Stow, it allows you to install a program in an arbitrary subdirectory(say,
I really think that's an incredibly good thing. For many reasons, and let me elaborate.
If you're at an unfamiliar system, or you're using a rescue disk, you might not know of, or have access to a package manager. You can't add nor delete packages, and you can't query packages. You don't know what files a package contains, and you don't know to which package a file belongs. I feel it's imperative that you can accomplish all of those tasks with standard *NIX utilities(ie: ls, mv, cp, ln, rm, cat, etc., etc.). To see what files are contained in the aforementioned Quake II package, I'd just need to do a 'ls -R
Of course, a good symbolic-link-based package manager should be a bit more complete. Now, RPM(I don't know about APT) uses a database to store its information. I gotta say, that's pretty stupid(no offense, RPM guys - I'm sure you have good reasons). At least, it's not very robust, from a system recovery/stability standpoint. So we want to get rid of a database. After all, we want to be able to manage packages with standard *NIX utilities, if we're really stuck in a bind. So, I guess each package would have some files, in its installation root(ie:
Requirements - Would have sections on both file-dependancies(ie:
Provisions - Would have sections on libraries and possibly a seciton on packages which the installed package replaces(ie: Postfix replaces sendmail).
PackageInfo - Would have a description of the package, and some notes on how the particular package may differ from the standard source distribution. Also some user-friendliness things like the type of software(ie: System -> Libraries) and such.
PackageConfig - This would contain the pre- and post-install scripts(yes, we really want to know what a package does!), and maybe anything that was done during installation based on any input the user gave.
These are just ideas, and I don't have the skills or time to implement them, so don't take it to heart too much
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Tri-Plus WinSpace, which I used at a job which forced me to use NT, did this famously. I tried a beta, and they had to send me instructions on hacking my registry to install the full version because the beta (demo) had a broken installer.
So perhaps you haven't had to do this, but trust me, other people have. Perhaps you just haven't lived life on the cutting edge enough to do this sorta thing, but I've had to do it several times.
One thing I would like to see is the ability to
do a rpm --rebuild target
eg rpm --rebuild php.src.rpm postres
I don't have LDAP, imap and all the other stuff that the rpm --rebuild php has. And its a pain
editing the spec file
is this possible now?
It's not a set number, it's determined by the painful but time-tested process of debugging and runtime testing; something that Linux developers never do enough of, I might add.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
The whole discussion thing will in the end boil down to something like a apt-get/Debian vs RPM/RedHat fight (..remember GNOME/KDE some days back ). Ok RPM doesn't have any automatic update feature ..so what ? aren't there scripts which can do it ?
.. i for one find it very comfortable to work with and would hate to read the man pages again !!
Just because the debian version seems/is/works better doesnot mean RPM is bad
The Linux Router Project is working on a radically different OS as well well as a new packaging system based on neither RPM or DEB.
/usr/local) with no
For the last 3 years I've done nothing but heavy development work and sysadmin. (For self and on contract) I've worked with Solaris, Redhat, and especially Debian, and can honestly say when it comes to 'real world' production systems all of them suck for long term system maintainance.
Out of all of them Debian is still best all around. (System and packaging) But it's packaging system could be a hell of a lot better. (I'm not still running 'slink' on my box because I want to...)
I think when we are done with our new breed OS, all the linux 'vendors' are going to be brought to task to look at how we did our packaging. Probably some of them will be adopting it. (That's is if we don't over take them all first. : >)
This is a feature list of what we are working on:
[name withheld]
==============
Defined:
A Unix type system software managment format, utilizing
a logical hiearchy for root layout, with de-centralized physical data
distribution.
Features:
No centralized package or physical data location
Allows conflicting packages/applications to be installed at the same time.
Package managment tool is able to enable or disable installed packages
dynamically, while preserving package configuration autonomy.
Generic and distributed nature. Multiple hosts can share the same
package installation via network mounts, while preserving package
configuration autonomy.
Allows hand fitting of root components (outside of
package conflicts
Logical root extensions for chroot, remote host, or virtual machine operation
'Open' physical packaging format allowing easy creation, extension, and future enhancment.
Don't look at the technology (RPM vs deb). Look at what the people are doing. What's going on in Debian's case is that they're doing a lot less (shoehorning each bit of software into their rule system) with a whole lot more. The sorts of things one finds in /usr/local
(that is, not distributed with the OS) on
a Unix you may well expect in /usr on a Linux
system, since Linux distros ship them. The
sorts of things which may live in /usr/local
on a non-Debian system probably live (if they're
DFSG-free) in /usr on Debian, simply cause it's
broader.
This is another reason Debian's so anal about its Free Software guidelines ... if it doesn't
meet the litmus test, then you can't distribute
some version of it with all the paths changed
to match the Debian universe, essential for
integration and stability.
True...but one doesn't have to use NoMad to use Encap. I actually use Encap on a Linux-Mandrake box(!) to keep track of what packages I've installed by source, rather than making my own RPMs.
:^)
Yes, this tends to break RPM, but hey, the article *is* about problems with RPM.
Stating on Slashdot that I like cheese since 1997.
When I begin coding software, I will keep modularity to a minimum
And the next month when it comes time to fix it or add a new feature, you'll change your mind. I'm curently in the process of evaluating code that was written 3 months ago for a web site with no thought to style or modularity, and the end result is the entire thing is getting tossed and redone from scratch, at a not insignificant cost in time and resources. If you think you're going to write code without regard to any accepted software engineering principles, you're an idiot.
Windows has the same library dependency problems you attribute to Linux, it just hides it slightly better at times, and makes it worse at other times. Remember trying to track 4 versions of slightly different VBRUNx00.DLL? Or how installing certain versions of Word just happen to change various system DLLs that break Netscape in new and interesting ways?
This
Yeah...and it shouldn't be a place for whiny bastards either...oh, well.
Stating on Slashdot that I like cheese since 1997.
To uninstall a package, you give the name of the package, not the name of the file that it was installed from. In other words:
rpm -e Mesa
I said I'd keep it to a minumum, not entirely shun it. Sure, there's cases where I'd want modularity (sound engine, 3d engine, net engine), but I'm not going to subdivide related parts of code into 16 different modules, as is the case in Linux.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I'm presently in charge of a project called "PMS" or "Package Management System". It's designed to work with all distributions, especially those without proper package management (ie Slackware). It will work in a model similar to that of APT, but automatically convert it to .tgz format or something along those lines. More information can be had here.
I was just looking at FreeBSD's source because I'm working on porting their /bin /usr/bin & /usr/sbin (for starters) just for the hell of it. What I've noted (although this will be obvious to most readers:)
1.) The whole system can be rebuilt by issuing a make.
2.) there's a possibility of merely patching an existing system.
3.) there's only one code base.
It might be nice of the LSBP to keep a list of "current" projects and to help maintain a FreeBSD-like set of buildable dirs, allowing an entire system to be built.
Alternatively, it'd be fun to put together a distro that does this--I talked to a guy around 4 years ago who was working on this at one time, the main problem being that Linux is merely a kernel and doesn't have a centralized authority as strong as other OSs. It would be nice to be able to, say, download a gzip'ed patch file, apply it to my source tree, and issue a 'make world' and have the whole system rebuilt before my eyes.
*Sigh* I can dream, can't I.
Stating on Slashdot that I like cheese since 1997.
As mentioned, the *BSD ports method is more flexable and better implimented than the Linux options but it's still not perfect. I think that the idea of looking at finding the next level of package management is what we need to do. It's what the article was basically about anyway.
---
--
If I actually could spell I'd have spelled it right in the first place.
So, depite the configuration flaws described in the article, apt-get's dependency resolution and package retrieval is already working for RPMs, so even those who dismiss interactive configuration as a completely useless feature will still be able to upgrade their RPM-based systems using apt-get. Kudos to Mr. Kojima and the Conectiva people for that!
Now could the other distros adopt apt-get as quickly as possible, please? Otherwise I'll be switching to Conectiva's distro in my next reinstall.
This is why many veteram Windows users routinely nuke their installation and completely reinstall everything once every 6 to 12 months--it's the only way to unclog the system's arteries.
I LOVE rpm! What could be easier than rpm -Uvh file.rpm?
If it doesn't say ".rpm", I won't install it.
If you don't like Debian, use Stormix then. It uses .debs too, *and* can still use the deb packages from the Debian website.
Je ne parle pas francais.
Oops. My mistake. :-)
The small amount of time that I have been with FreeBSD, I am amazed at the power and flexibility of the ports system.Sure there's a few rough spots, but those are easy enough to polish out.
For those that don't know, where the synopsis: the ports system is a collectin of makefiles and diffs to properly fetch, extract, configure, build, install and register a software package for the target system. A FreeBSD package is simply a port that has been precompiled, so you don't have to be afraid of typing "make" at the commandline. And these packages have utility programs along with them, like pkg_add, pkg_remove, pkg_info, etc. Dependencies are kept track of, including checking for individual libraries instead of monolithic packages. Very similar to Debian's method.
So how does this fit into the Linux continuum? Well, right now there is a concerted effort to make a unified BSD ports system, instead of separate ones for each *BSD. There is no reason that Linux could not get involved so that there will be a linux-ports variant. Hell, there's no reason that it couldn't be a grand unified UNIX-PORTS! And there's no reason that deb and rpm packages can't be fit into the system as well. I keep hearing rumours that Slackware will go to a ports-style system, and I hope they do.
If you're a potato or hamm head, and have always criticized the ports because it didn't have some minor feature, now is the time to get involved.
A Government Is a Body of People, Usually Notably Ungoverned
I just spent about 3 hours making a port of one of my old DOS games to Linux. That's 3 hours from opening the SDL (Simple DirectMedia Layer) documentation, to compiling the final build of the game. I wish I could say the same about DirectX. That system is terrible! It took me a week to make the same port for Windows using DirectX (which was quite a hack).
z
Developing in Linux is a joy. Gcc, Makefiles, etc. It's no different than when I worked with Unix or with DJGPP for DOS. VC++ is like a trip to another world. Must have a GUI frontend? Kdevelop is very good. I am not much of a GUI programmer (I can barely make a KDE or Windows program), but I've heard nothing but good about Trolltech's QT system. I cannot say the same about MFC or Win32.
You think Windows is not a huge mob of code? I'd worry more about the stability of my Windows programs than my Linux programs. Win32 is just such a mess! It's the type of architecture where you are afraid of the API.
If I must make a Windows port, SDL and QT thankfully support Windows. But I will develop in Linux.
-Justin
BTW if anyone wants to try out the game, check out http://www.affinix.com/~justin/munchman-1.0.tar.g
I think it's pretty cool still, even though I made the original DOS version in 1997.
Let me clarify (to allay a few of the flames) that I think all of the things on my list should be doable while I'm deciding what to install, preferably without downloading the whole package. I know I could do most items by writing a script to download the new package, possibly unpack it into a temp directory, and poke around. But imagine if you had to do this just to read the description of the package. I'm proposing that all of the things I list be as readily available as the package description.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I am in favor of RPM's, and personally, I like to build from source. I try and use SRPMS as much as possible, but they have absolutely insane dependencies at times. Installing, and building the SRPMS for openssh for example, require that you have gnome stuff installed. Why, because it wants to build gnome-askpass... It might be that the guy who build the package was asleep at the wheel, but it is highly aggrevating to have to edit the spec file every time I want to build something from source. They have a tendency to built into big monolithic pile, where you have to have them all or your stuck. I was trying to build a router, that I wanted to be highly secure so I build all things from source that didn't come off my official red hat CD, and it ended up having gnome development libraries, which required X, among other things. Note, change of topic: I have used ports on FreeBSD, they are very nice, I have found that RPMFind can approximate the same thing. The issue with ports, is that they are all centrally controlled by one small group of people. If they decide to not add some new package you want, you can't have it. If I write a port, I would have to submit it to them for the next update of ports. I am not sure I really want my packages in someone elses hands. I like FreeBSD, I thing they do lots of good things. I just don't want all my packages in there basket. Kirby
The version in Potato is not up to date, though; grab the version from unstable, and you'll be in heaven.