On Fri, Dec 13, 2002 at 10:48:32PM +0800, Dean Michael Berris wrote:
> On Fri, 2002-12-13 at 19:57, Ian C. Sison wrote:
> 
> > I believe your reluctancy to consider the advantages of package managers
> > and dependencies stems from this statement you made above, so i need not
> > rebut your other points below.  Dependencies are there for a reason and if
> > one cannot appreciate its advantages, then a discussion of its merits or
> > demerits on the same level cannot be done.
> > 
> 
> building from source (of course reading the README, INSTALL, etc. files
> and knowing what to do beforehand) is still the best way of installing
> applications IMHO. and i believe that during the part where you try
> doing './configure' on the command line tells you that YES, there are
> dependencies. but then like i said, you could see them even before you
> even try to configure the application you are about to build from
> source.

It is still the best way - you can audit all you want - but lest we
forget that compiling your own build takes a lot of time too. I learned
this the hard way when I backported _a lot_ of packages from Woody and
Sid when I was still using Debian Potato. Takes away a lot of time to be
used for more useful things [for A to compile, you need B. So get B.
Then you learn that you'll need C... transitive effect]. Too much time
consumed.

> > Mandrake comes with its own kernel and a plain vanilla linux kernel,
> > and i believe debian ships a plain vanilla linux kernel as well.
> > 
> 
> and which one does it install for you? i know that the modules you dont
> need for hardware you dont have are included upon installation. yes, the
> vanilla sources are there, but then i wouldnt go on saying how mandrake
> didnt function right when i correctly configured and made a lean vanilla
> kernel for my system. so i wont. ;)

Debian ships with a slightly-modified vanilla kernel (mainly stability
or bug fixes only) but more or less it's a vanilla kernel.

Anyway, for those who've experienced being bitten by a vanilla kernel
not compiling - have you tried switching compilers? gcc-2.95.3 is still
the recommended compiler. [there was a time wherein I couldn't compile
an RH 7.1 stock kernel using the RH source with the default gcc-2.96 -
but that was about a year ago]

> > Any bad experience may mean several things, and certainly DOES NOT
> > automatically mean that the particular technology is broken or
> > fundamentally flawed.  Most of the time it means it was not used properly.
> > 

> i dont remember saying that the technology is broken or flawed. yes, it
> [referring to rpm] has more features like dependency checks, etc. but i
> again would like to say that no thank you -- i do not need them. why?
> because i can work without them. and i _personally_ do not think that on
> the basis of merit such as ease of use, that i will want to use it --
> because i primarily do not see it as an advantage, rather a mere
> complexity (which i might say is for me, unnecessary).

It is perhaps the prerogative of a VAR (such as a distribution company) to
offset the need for the end-user to compile his or her own packages, or
better yet actually mind what software does package A depend on. Of
course you can choose to override it - you can - but just beware of
possible consequences. (That's why they're called VAR - value-added
resellers - in the first place).

Now, if you're not really happy with that policy, you can always choose
to override the policy of a package manager. Or even try building
everything from source (ala Gentoo or LFS - just be very careful
though). At the very least a package manager will simplify things (which
I think should be the job of software - to simplify the process of work). 
 
> > > ever wondered why the slackware packaging system is still around? yes,
> > > there are fancy dependency checks, and auto-install features in some
> > > packaging systems which i may repeat -- I (personally) DO NOT NEED. that
> > > which i do not need is bloat to me.
> > 
> > Yes, as i said many people do not appreaciate the benefits therefore claim
> > that they do not need it.  Unfortunately, many people also do not
> > understand the technology, use it incorrectly, experience catastrophic
> > failure and then knock it down later claiming it to be not useful to them.
> > 
> 
> what benefits are there that i can achieve using rpm over tarballs? i
> fail to see the merit such as 'ease of use' be a factor to me - but then
> i might be alone on this one. another is like i have earlier stated
> these features (like dependency checks that i can do myself) are
> complexities that to me are not necessary, and not an advantage.

Ease of use and reclaiming more time for more productive work is what I
think is a big factor (consider replicating this to a lot of machines).

> > > but ill face it. sure, slack doesnt offer these services so its just
> > > mandatory that i not need it in my current situation. but i've been able
> > > to work without it, which goes to show that yes, i can live without
> > > automatic dependency checks. sure, i'm a bit masochistic you may say,
> > > but then that's me. ;)
> > 
> > People can live without a lot of things.  In some areas of the country,
> > there is still no electricity or phone service.  But they are alive, and
> > their existence in the planet is not threatened.  People adapt to the
> > environment they are used to.  And you can't blame them for not being able
> > to experience, use, and appreciate  better technology.  And you can't
> > blame them either for NOT WANTING to use better technology as well.
> > 
> 
> i wouldn't consider a more complex technology as better. take the pencil
> -- why can't we get rid of it? because it works. sure, there's the
> ballpen which runs out of ink, but then the pencil still works. which
> technology is better? well, i would say neither because they're two ways
> of serving the same purpose -- but i would go on to say that
> theoretically speaking, the ballpen in a more complex technology than
> lead in the center of a wooden stick. that doesnt make it [the ballpen]
> better.

Analogy - transportation [in an extreme view] is a luxury. Why - you can
always opt to walk, or swim [across the ocean - yes - assuming that you
won't get tired]. However, we tend to neglect that doing some things
manually takes a lot of time. 

Computers, on the other hand, have this "gift" of processing things faster
- what is wrong with using such amenities to alleviate you in your task?


Back to the transportation analogy - there's nothing wrong with walking
(discounting the air pollution - it's a great way to trim down those
beer bellies). We're not proposing of getting rid of the process of
walking - nor are we discounting the simplicity of the absence of a
package management system - it's just that having transportation or
using a package manager alleviates us (through saving us a lot of time).
Then you can use the saved time to do other things (productive or
otherwise).

A nearer analogy - you can always hand-compile when optimizing. But
isn't compiling the job of a compiler? Note that not in all cases would
you settle for solutions either way - there'll be cases wherein you'll
trade one for the other.

> yes, tarballs have been the first ways of packaging in linux. but why
> dont we get rid of it? well see the pencil argument. ;)
> 
> > 
> > The difference between us - i respect, since you've obviously made up your
> > mind already, however there must be someone who can explain to the list
> > the other side of the 'slackware advocacy' thread.  There are others on
> > this list who can benefit by knowing both sides, and leave it up to them
> > to make a sound decision.
> > 
> 
> i happen to think that yes, rpms are a big convenience to use. please
> take note, _convenience_.

Unfortunately, this convenience saves some time. Time is also a valuable
resource.

I'm not saying that you should always value time over simplicity ->
there might be some instances wherein you'll need to offset one with
another. (aside from not in all cases is simple != easy || simple != fast)
Relating to the rpm and tarball technology - tarballs are marvelously
simple, but it isn't always the case that things will go easy. RPM, on
the other hand, will bug you first of settling all dependencies before
offering you the convenience of running the package upon install (minus
the hassles of configure, build and install). In some cases you may opt
to override the policy (e.g. in my opinion I won't need debs for
OpenOffice, as the binary tarball already runs out of the box). YMMV.



-- 


Paolo Alexis Falcone
[EMAIL PROTECTED]

"Time is gold, but we need cash."
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]

Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph

To subscribe to the Linux Newbies' List: send "subscribe" in the body to 
[EMAIL PROTECTED]

Reply via email to