This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Postinstall script ordering in setup - take 2


On Mon, 2003-03-10 at 16:18, Igor Pechtchanski wrote:


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

For some value of installed :}. Actually package dependencies are fairly
strict: we can't run any files from package B until package A has run
it's postinstall script (i.e. is fully installed). This appears
isomorphic to scripts to me.



> I agree that "redundancy leads to inconsistency", and specifying script
> dependences will also require specifying the necessary package
> dependences.

(*)

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

I think 20 is a huge exaggeration. I can think of -at most- 3 that we
need. I allowed for 5 above to give some elbow room. 

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

I'm not worried about preferences: I'm worried about robustness.

>   It could be specified using
> helper packages, but generating them by hand is error-prone and easy to
> lose track of.  

(*) As oppossed to syncronising the needed packages with the needed
scripts, and ALSO tracking changes in the script names?

> If the use of package dependences were mandated

No if here. Package dependencies ARE mandated TODAY.

> , maybe we
> need a tool that would convert script dependences to package dependences,
> and generate the necessary helper packages...

Thats an interesting idea. It allows you to follow your preference,
shrinks setup.exe's code (no need for setup to know about script
dependencies, only the package DAG), and would be useful.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]