Re: Conflict/dependency granularity
On Mon, 7 Aug 1995, Richard Kettlewell wrote:
> Bill Mitchell writes:
> >Not so much underestimating their intelligence as making a
> >judgement about their inclinations.
> [...]
> >administration, and don't want to know. They just want to use
> >the machine as a tool. They don't want to maintain the tool).
>
> Fair enough. But how much are such people going to be installing
> random software grabbed off the net?
The illustration which comes immediately to mind probably isn't
a good one. The spiffy color ls program provided with SlackWare
(which I personally don't like and would rather not install)
really grabs lots of people. Not available on your debian system?
No problem. Just let me mcopy it off to flopy disk for you, and
you can put it in /usr/bin.
In this particular example, the ls program could no doubt go
in /usr/local/bin just as well (though there might be a config
file which needs to go in /etc), but there are probably other
examples which need to go into /usr/bin. A cooperating
system of programs, possibly, which have it hardcoded
to look for one another in /usr/bin.
> >What we're doing with our packages is analagous to what's done
> >in the DOS/Windoze world with shrinkwrapped applications, but
> >complicated by dependencies between our packages and conflicts
> >between packages we provide and with packages and applications
> >provided by others.
>
> Such conflicts still exist in DOS and Windows - it's just that there's
> no standard mechanism for finding out about them.
Probably. Are you offering that as an argument that we should
leave the area unaddressed when we could address it? That is
a decision point for us.
>[Re: /bin/fmt, /usr/bin/mt examples]
> But: I think there is a very strong case to be made for individual
> packages being `plug and play' - no messing around looking for some
> new version of mt to patch in on top or anything like that. I'm
> simply not convinced that the examples you give demonstrate a real
> problem.
Well, for so long as the broken programs remain broken, and repaired
versions don't reach all debian systems, they'd be a problem for
users touched by the brokenness. Better examples probably do exist.
The ones I used were handy.
> [...] file dependencies could still cause problems. How
> do you depend on /usr/lib/gcc-lib/i486-debian-linux/2.6.3/libgcc.a,
> for example? That version number is going to change one day
> ... perhaps likewise the 'i486', and even the 'linux' if there were a
> Hurd-based Debian. In this example, a virtual package would win.
Perhaps I wasn't clear. I wasn't proposing that current dependency
schemes be replaced with file dependencies. I was saying that
the ability to specify file dependencies might also be useful in
some cases.
>[...]
Reply to: