Re: More on Kpackage

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Al" == Alex Hudson <eah106 [at] york.ac.uk> writes:

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

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

Yes, no.  I mean, you're exactly right, sometimes there is no good
reason for a particular dependency, no.

In this particular situation, --force-depends is a way to test whether
the software would work (indicating a bug in the package database or
perhaps cross-distro version skew) or not.

    >> 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?

    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.

    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.  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!

    Al> I refuse to believe that versioning should even exist; there's
    Al> no point. 'I need this service'.  'I provide this service'.

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.  ;-)

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!)

    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?  ;-)

    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.

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.



Footnotes: 
[1]  More because it's too cool to leave alone than because it's less
effort than simply making myself do a CVS commit every day ;-)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
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.