Re: More on Kpackage

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

(Found it!)

>     >> And with something like PAM ... I like knowing that fixing a
>     >> bug in login means it will also be fixed in ftp ....
>     Al> You're putting up straw men here - we're talking about
>     Al> libraries, not the more general case of distributed code
>     Al> and/or code reuse... ;)
> Huh?  How do you patch login's source and simultaneously fix the
> _installed_ binary of ftpd [typo above] if PAM is not a .so?

Distributed services, like even Samba or something, can do authentication
from anything - all you need to do is know who to ask for authentication.
There's loads of different ways of doing stuff like that. But, when it comes
down to it, you're comparing apples with pears because I wasn't advocating
.a's as an answer to .so's in terms of (non-compiling) software reuse; I was
advocating them because for my setup it's easier.

>     Al> No it isn't. I don't give two hoots what version I have on my
>     Al> system, furthermore, neither should my system...
> Then you've just assumed away the version dependency problem.

Yes. ;)

>  Of course we don't need package managers then, I agree.  Unless it's the
> package managers that made version dependencies moot in the first place!

This is verging on the philosophical, I fear...

> What if "I provide service A" turns out to be a lie?  Excuse me, I
> mean there was a bug in the implementation.  So we now provide a new
> service called "service A with bug X fixed."  A version by any other
> name still stinks like shit, I'm sure you agree.  ;-)

The crux is maintainence. With .so's, if you need a particular version
(b'cos of some dependency or something), and you don't have it, you need to
get it. Similarly, with a versionless library, it needs to be maintained to
be considered functional. The question then is; how does my app realise the
library is stale, and how to I go about getting the user to update it?
Comparing version numbers is a simple, albeit dumb, way of doing things.
It's something the user shouldn't need to concern themselves with; since
it's something easily done by a computer. This question is immeasurably
harder with standalone machines, since the machine only has itself for
verification of 'staleness', but that's not really where the future lies
anyway...

> It's just a question of whether providing an enormous array of
> service-by-service versions is a better way of dealing with the issues
> than encoding that vector into a single linearly ordered series of
> version numbers for the whole library.  (I can just see glibc see
> saying "I provide scanf 1.0, sscanf 1.1, fscanf 3.1, printf, sprintf,
> vsprintf, ...".  Uh, maybe not!)

That's if you version everything; I'm talking about versioning nothing!

>     Al> Are you making fun of my use of CVS trees? ;)
>
> Not at all.  I do what you do, too.  But some times I forget to init
> it on a new box, which leads to a scramble of checking in and merging
> and cross-checking names---that's why I need /etc/skel/CVS.

Ah yes, I understand now. I don't often get new boxes (student), so I'm not
familiar with this problem....!

> Actually, though, I'm probably going to go to Coda file system,
> instead, for the purpose of synching.[1]  Versions will still be done
> through CVS.

As I said in reply to another e-mail, that's something I'd like to try out
myself. I have SuSE 6.4 knocking around (uninstalled as of yet, due to time
constraints), so I may go for reiserjfs (/) and coda (/home, maybe
/usr/local.. and /var/spool.. too, although e-mail poses a tricky problem
;).

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.