Some of this was him responding to Zentara. I'll respond to that which was
in response to my mail. Also note that most of the mail was in response to
obvous newbie RPM issues with Zen. I mostly only responded to what was
directed at my own statements, as the stuff Zen said and what the
reponse was doesn't really apply to me. Warning: I'm a little pissed by
this sad man who flamed us, and their is the occasional harsh word. ( Well
maybe not so occasional). If you have a problem with that, then please
just hit delete now, rather than looping this into an endless flame war.
On Fri, 15 Jan 1999, Jeremy Blosser wrote:
> I forwarded this message to a friend of mine who's really big on RPMs to
> see what his comments would be. He asked me to forward his response to
> the list, so I am. Note that I didn't write it :) He isn't on the list,
> so if you're going to flame/respond to him, cc him.
>
> ----- Forwarded message from Mark Bainter <[EMAIL PROTECTED]> -----
> > Michael Johnson [[EMAIL PROTECTED]] wrote:
> > >
> > > I agree with Zentara. I know plenty of people, that code and that are
> > > involved in bigtime linux projects ( i.e., that know their stuff ) that
> > > hate RPM. It's not just us being nuts.
> >
> > Ok, so what you are saying is that because some unnamed people working on
> > unnamed projects don't like RPM it's not viable? There are people out there
> > with big-names and big-projects who hate kde, that doesn't mean jack. Some of
> > them hate X entirely (mostly for ludicrous reasons like 'It's graphical
> > therefore it's windows-like'.
Mandrake for one. Lots of others. Not the point. The point is that you are
not insane, as what is being implied, if you don't wet your pants over
RPM. I _do_ like RPM, but I also like sources. And your analogy is as
vacuous as most of this mail. We aren't talking about X and KDE, lets
stick to the f**king point ( if you can ).
> > > With RPM, you are stuck with
> > > 'default' settings of the RPM packager. Most of them aren't relocatable.
> >
> > Yes, this is true. Creating relocatable packages is time consuming, and when
> > you are creating a package for a given set of users (i.e. redhat/SuSE) you can
> > generally assume most have the same setup (as defined by the distribution) and
> > use that. If someone has something different or wants it installed
> > differently then they are more than welcome to create their own. In fact,
> > it's really easy to make a change like that. Just unpack the src.rpm. Edit
> > the spec and change the ./configure or make install line to set the prefixes
> > you want, do an rpm -bb and you have your rpm.
I already KNOW HOW TO BUILD RPMS. I BUILD RPMS ALL THE TIME. I simply
said, RPM as it's standardly used, is to install packages for people that
don't build from sources. The reality is if you have to roll your OWN RPM
then you ARE basically BUILDING FROM SOURCES, anyway, with only 2 or 3
steps added. Why do you automatically assume we don't know this obvious
shit, anyway? It's so typical of you people (zealots for something,
usually RedHat users ) to
have read a mail, and to make assumptions about people you don't even
know-- you don't know what my level of knowledge is, for instance, or you
wouldn't have sent this mail--and then to make your silly little flame
statements based on something you observed without really knowing what the
HELL you're talking about. I KNOW how to work with SRPMS. I KNOW how to
build RPMS and SRPMS. I KNOW how to edit a spec file. I do it all the
time. It's not hard at all. But anyone that knows all this can just
build from sources, without the tedium of the added steps.
> > > And you really have little control over the configuration of the package.
> > > You just have to assume it's all o.k. Take lynx. If I want an ncurses
> >
> > How is this different from a precompiled binary?
There IS no difference between it and a precompiled binary. That's the
whole f*cking POINT. READ MAIL BEFORE YOU SPOUT THIS STUPIDITY.
> > You still have say in how your system works. If you want to know how it was
> > configured, unpack the rpm and look. If you want to know what files it will
> > install and where do a rpm -qlp <package>.rpm and find out. When I package
> > rpm's I put any special configuration items in the description as well.
> > If your above issues regarding configuration hold true your are building for
> > sources anyway so why not use the benefits of rpm? Can it tell you before you
> > install it that it's going to break something else if you do? Or that you
> > need another package for it to run? Will it warn you when you are removing a
> > package that other packages were installed that depend on the one you are
> > trying to remove that you weren't aware of?
I don't need it to tell me all that. I know my packages. I know what they
need. I know how to compile them, and what they require. I know how to log
what I am doing, and what config files will be installed. I know what the
dependencies are. All this stuff that RPM does can be done manually by
anyone with a brain. The whole point of RPM was to make life easier and
sometimes it does. The reality of it is, RPM is just a way of automating
stuff you'd have to know anyway if you were building a source package.
RPMS let the clueless get away with being clueless. Sources don't.
What makes you assume I don't know how to query packages? I do.
Once again, assumption. I know how to query installed or not yet installed
RPMS. I have sent many a mail on this list and others telling others how
to do it. The reason why I don't build RPMS everytime I build from
sources, is because that extra 2 or 3 steps gets tedious when you are
compiling something huge, like CVS gnome, or GNUstep. I know my system as
good or better than probably MOST Linux users. I can track what is
installed. I also know what things need and don't need. Alot of the RPM
deps are WRONG anyway. The deps aren't always true DEPS but pristine
settings decided by the dist. For instance in RH if you install Gnome it
demands you have XScreensaver. You don't need XScreensaver, but it does
work with part of gnomecc. And yes, you can tell what it'll break before
you install it from sources but ONLY IF YOU KNOW WHAT YOU ARE DOING. I've
been doing Linux/Unix for years, and the occasion where I break something
is SO F*CKING RARE, that I can't remember a SINGLE CASE offhand. RPM is
great. I DO like it. I'm just saying I prefer sources sometimes for some
projects.
> > I'm not saying all of this can't be done another way (tripwire, constant
> > journalling of everything you do on the filesystem/etc) but imo anything that
> > saves me time as a sysadmin, and cuts down on the risk of my missing something
> > and thus causing myself grief is a good thing.
Well, bravo, for you for admitting you don't have a clue and that you
want to use RPM to protect yourself from your own incompetence. I admire
that humility, but I don't share it cause I don't have to, cause I have a
clue, obviously you don't.
> > I
> > > think one day RPM may have a front end to have more custom control, but
> > > it's no day soon. Other things: If you are dealing with unstable apps,
> > > there's usually no debugging info, so if you were working with an app and
> > > wanted to help narrow down misbehavior you'd be better off recompiling it
> > > anyway, so that you can give meaningful information to the developer or
> > > try to find out the cause yourself. I think RPM is great for building the 'core'
>dist suite, and
> > > after that you're on your own.
> > > As far as uninstalling goes: Many recent apps also have a 'make
> > > uninstall' option so you can painlessly remove stuff. People building from
> > > CVS use this all the time. Also you have instmon, which if you write
> > > scripts can be handy in building a build removal script if neccesary to
> > > assist the removable of source installed apps. So removing these apps
> > > isn't as difficult as the poster implied.
> > > -M
> > >
> > But not all have this option. And if it does, you are still depending on the
> > 'builder' to be sure everything is working properly. How is this different
> > from RPM? And can your scripts verify that all the files of a particular
> > package are installed? Can it do checksums to see if it's the same file as
> > was originally installed? Will it overwrite config files or rename them?
> > Can you find out what package installed a particular file with them? Do you
> > get any of the system administration benefits that RPM brings besides
> > install/removal of packages?
I'm not saying it is TOTALLY different from RPM. Installing from sources
is only a problem, if the installer, ( people like yourself) are worried (
seems with good cause in your case ) that they really don't know what the
hell they are doing. I can check what something installs and yes I can
monitor it. RPM DOES have great benefits, and I do use it, just not all
the time. You can check your installation. You can also check what it will
do or SHOULD do, in the event you install it PRIOR TO EVEN INSTALLING THE
PACKAGE. Also, depending on the case, ( developer stuff ) I might not want
it installed into my main system anyway but a 'test pocket'. I don't
always NEED those
benefits. They are nice to have,
but they aren't always neccesary. RPM appears the perfect solution but
it's not. THat was the point to my original mail. I'm sorry if you can't
understand that. Note: RPMS are still just source packages. The same rules
that apply to sources apply to RPMS, like knowing the dependencies of a
package, etc etc etc. So the quality of the RPM is based on the
knowledge of the builder. In many cases I feel as secure if not MORE
secure with my knowledge than I do with some of the knuckleheads that
build some of the RPMS for certain dists. Alot of the deps are whacky, the
locations of the install can be frigging nuts. They often bloat the
install by adding things I don't need, like additional FAQ, and docs, etc.
RPM is great if the person who built them wants from his build what you
do. Most of the time, I find ( especially with RH) that these people don't
build things as I would anyway. For instance, they often split up includes
etc from the binaries. Well that's all good and fine, for some people, but
I find all this splitting up and scattering things about into all these
little packages annoying at best and RedHat and Debian are famous for
this. Most of this is based on what seems to be a trend started by RedHat
to make the dist as dumbed down as possible to spread the popularity of
Linux, thus doing all it can to help someone who is either 1) new to linux
or 2) hopelessly stupid and inept, while at the same time discriminating
against people who commit the cardinal sin of having a damn clue.
> > 'all other packages' I disagree with. Netscape maybe true in this case, but
> > many packages install files in several different locations (/opt /lib
> > /usr/include, ad nauseum)
Yeh, 'ad nauseum' for you, cause you still need to know how to read.
Tee can track all this. Reading a makefile can test this. Instmon can
track this etc etc etc. Anyone with a brain can file and log everything
that happens from the download, to untarring, to ./configure to make and
make check and make install. Every step of the process CAN be monitored.
The reality is in many cases, most packages install just a few manpages,
an unstripped binary, and maybe a config file, anyway. Only with really
large
complex projects would this even come up. You really don't get it, do you?
You are completely clueless, don't know what the hell you are talking
about and yet have the temerity to try to flame us. We could sit down and
talk Linux anyday and if this mail is any indication of your
knowledge I'd rip your ass to shreads and I think I'd do it
everytime. Your arguments aren't even thought out and yet you have the
audacity to flame and while flaming basically admit that you prefer
using RPM not because it's so great but because you are scared that you
don't know what you are doing, and that fear is basically apparently
justified. Never assume we're inept just cause YOU are.
> > If you don't trust it, unpack it and inspect it. use the source rpm. do a
> > rpm -qlp (as mentioned above) and look at what it's going to do. install it
> > using --root /somedir/ and look at what it does first. BTW, you don't *have*
> > to install packages as root. You just can only access the main rpm database
> > as root. Think about it. Do you really want your users able to modify the
> > main rpm database? I don't. if they install a package, it should be to their
> > home accounts (using --root) and defining their own rpm database (using
> > dbpath).
The rest of this stuff is basically the flamer ( who seems to be a bit of
a lamer ) responding to some newbie issues Zentara had so I won't waste
any more time responding to it. Yes, I know how to build RPMS, yes I know
all the long and short arguments to the rpm, yes, I know that RPM is
conveniant and
handy. But yes, I still like ---for SOME THINGS--- to work with sources,
because I find RPM gets tedious ( and this isn't cause I 'don't know' how
to use RPM, I do, I just prefer even in knowing how to use it to
sometimes opt to NOT use it). I think for someone with the
ability of the flamer, it's perfect though, cause it requires less of him
knowledgewise in pertaining to Linux for him to function.
As far as fud goes, it was a case of the pot calling the kettle. Go back
to your little RedHat list or wherever this came from and go find people
on your level to argue with rather than sending flames to people you don't
know without really knowing what you're saying.
Don't get into a flamewar with me little man, you won't win. You're
outgunned.
-M
-
To get out of this list, please send email to [EMAIL PROTECTED] with
this text in its body: unsubscribe suse-linux-e
Check out the SuSE-FAQ at http://www.suse.com/Support/Doku/FAQ/ and the
archiv at http://www.suse.com/Mailinglists/suse-linux-e/index.html
