On 10 Mar 2003, Robert Collins wrote:
> On Wed, 2003-03-05 at 11:41, Igor Pechtchanski wrote:
> > On 5 Mar 2003, Robert Collins wrote:
> >
> > > On Wed, 2003-03-05 at 08:19, Igor Pechtchanski wrote:
> > > > On 5 Mar 2003, Robert Collins wrote:
> > >
> > > > > Using the packages as dependencies we can build the same topological
> > > > > tree based on the packages that will end up as installed (Because we do
> > > > > know which package has which postinstall script).
> > > >
> > > > Yes, but using scripts is more fine-grained.
> > >
> > > What granularity is needed that isn't present today?
> > > Rob
> >
> > Well, one example I could think of off the top of my head is mutually
> > dependent packages. Package dependences can be circular, script
> > dependences cannot.
>
> Sure they can. All it takes is two maintainers marking the other script
> as a requirement.
Oh, of course you can *have* circular dependences, but you can't *honor*
them. Script dependences mean that some script has to be run before the
other. It's a partial order. Package dependences are less strict, in
that they don't require package A to be installed before package B is
installed, only before package B will run...
> > Suppose we have packages A (containing A1.sh and
> > A2.sh) and B (containing B1.sh and B2.sh). Currently we can specify that
> > A should be installed for B to work, *and* that B should be installed for
> > A to work. However, we can't specify, for example, that A1.sh should run
> > before B2.sh, but B1.sh should run before A2.sh. We could say that
> > postinstall scripts in mutually-dependent packages will run in an
> > indeterminate order, but we'd have to run either both B?.sh first or both
> > A?.sh first. Even combining them into one package will not ensure
> > postinstall script ordering. The only solution I see, aside from adding
> > script dependences, is a bunch of almost-empty helper packages...
>
> I don't see that as a particularly good or bad solution. I think that
> leveraging package dependencies is better from a couple of points of
> view:
>
> 1) It reduces the 'do n things on install' to 'do 1 thing on install'
> that must be prevalent to have mutually dependent postinstall scripts in
> the first place.
> 2) It can be precalculated *before* downloading packages. With
> postinstall script dependencies, there is *no* guarantee that the
> package containing the needed script will exist. At least with package
> dependencies we can warn before downloading that a required package
> doesn't exist.
I agree that "redundancy leads to inconsistency", and specifying script
dependences will also require specifying the necessary package
dependences.
> So: I see what you mean by granularity but script dependencies can also
> be circular.
See above.
> I suggest that the pragmatically needed granularity does
> exist at a package level, given that only a few (< 5) such core packages
> are needed, and that for larger packages (i.e. tetex) the common idion
> amongst rpm and dpkg distributions of a -common package will serve us
> well.
Most likely. However, anything that increases a newbie user's confusion
upon install is not a good thing, IMO, and seeing 20 dummy packages is not
going to be very enlightening... :-)
> Which brings me back to : what is remaining about script dependencies
> that makes it more suitable as a long term solution? (And memo to self:
> check code to ensure that we sort generate a DAG of postinstallscripts
> by packages today).
> Rob
It might be a matter of personal preference, but if a postinstall script
depends on some other having been run (base-files-mketc.sh, for example),
I'd rather specify this in the script itself. It could be specified using
helper packages, but generating them by hand is error-prone and easy to
lose track of. If the use of package dependences were mandated, maybe we
need a tool that would convert script dependences to package dependences,
and generate the necessary helper packages...
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
