Re: More on Kpackage

["Alex Hudson" <nospam [at] york.ac.uk>]

> RPM must have a --force-depends (ie, ignore dependency errors) option?
> It's really hard to do a mass upgrade without one.

I would imagine it does; that's no reason for people to use it though. "Oh,
it didn't install. I'll just force it then." Surprise, it still doesn't
work..... dependencies are there for reasons, no?

> vs. Al on .so's:

Oh goody ;)

>     Al> What's happening (obviously ;) is that it can't see
>     Al> libjpeg. Admission first: I hate libraries. I compile all my
>     Al> software statically. I think libraries are the spawn of the
>     Al> devil himself [1], and I refuse to use them, have no knowledge
>     Al> of how they work, nor do I care about that !!
> Boy, you're going to enjoy the 25MB footprint of your new XFree86 4.0!
> The rest of us will use the .so-ized drivers, and weigh in at about
> 1MB ;-)

Usually, the bloat isn't quite as big as that. I can't say about XF864, I
haven't played with it yet. But I enjoy the benefits of being able to move
software from machine to machine without having to play silly buggers with
installation ;)

> I've had few version dependency problems with Debian, except in cases
> where both the app and the library are bleeding edge (and the library
> developer goes on vacation and the app developer uploads his
> latest-and-greatest to the Debian archive anyway).
>
> And with something like PAM ... I like knowing that fixing a bug in
> login means it will also be fixed in ftp ....

You're putting up straw men here - we're talking about libraries, not the
more general case of distributed code and/or code reuse... ;)

>     Al> version dependency problems should install to a CVS tree by
>     Al> default, and whenever you need a specific version of a
>
> But _which version_?  That's what package managers are for.

No it isn't. I don't give two hoots what version I have on my system,
furthermore, neither should my system...

>     Al> library, you just check it out. But then, I have /home/alex
>
> Why use such a coarse granularity?

Storing a library in CVS is *coarse* granularity ?? ;)) I refuse to believe
that versioning should even exist; there's no point. 'I need this service'.
'I provide this service'. That is all that is needed. Not, 'I am the latest
and greatest. I have more functions than my previous incarnation. I also do
the same thing, but I'll be a big cheese rabbit in a floppy hat if I'm going
to let you use them in the same way as before'. I hate it when APIs change,
I hate it when libraries become binary-incompatible, it's just a big load of
poo. An application shouldn't need to know which specific instances of
libraries it needs. It should need to know which services it needs, which is
a (subtley) different matter. We start, then, to get into the realm of CVS,
Jini, CORBA, etc., which is (IMHO!) on a slightly higher plane of existence
;))


>     Al> installed to a CVS tree, so perhaps I'm just a VS-nut...
>
> Hey, that gives me an idea.  I don't have /etc/skel/CVS yet, but I
> think I need it.  Do you think?  ;-)

Are you making fun of my use of CVS trees? ;) I won't have I tell you!! :))
Actually, I do have a very good reason for placing my home directory in
CVS - I can resync with my laptop in style. Very nice way of doing things; I
wish distro's would give you the option of doing this by default. A sort of
cvsfs, or something. Doesn't work for all types of file though, which can be
slightly annoying, due to the way diff works out, but it doesn't take up as
much space as you'd imagine (I curtail the tree to previous one or two
syncs, since by that time I've had my chips).

Cheers,

Alex.

---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.