Managing required packages in nALFS

Vassili Dzuba vassilidzuba at nerim.net
Fri Sep 13 10:46:49 PDT 2002


On Fri, 13 Sep 2002 16:12:17 +0000 (UTC)
jamie_bennett at pcpmicro.co.uk (Jamie Bennett) wrote:

> > -----Original Message-----
> > From: Vassili Dzuba [mailto:vassili.dzuba at wanadoo.fr]
> > For the time being, the <check> handler aborts the processing
> > if it is not satisfied, so there is no problem with many levels of
> > dependencies ;-)
>  
> Yeah, I was writing a patch that would list _all_ packages that a 
> particular profile depended on. Kind of like Gentoo's portage that
> can do a pretend build i.e. show you what _will_ be installed if
> you want to proceed. I quickly realised that some kind of 
> recursion was needed to traverse dependencies rather than list 
> just the one that were in the current profile.
> 
> > However, if we want to support the automatic build of the packages
> > we depend on, i think it is not too difficult as the current 
> > processing
> > is already recursive.
> > 
> > The handler for the <check> element could do :
> >     - check if the required package is available
> >       - if yes return
> >       - if no :
> >         - retrieve in the XML tree the element corresponding to the
> >            required package (that's the most difficult thing to to)
> >         - process it as it were a child of the <check> element
> > 
> 
> This relies on the fact that we need to read in _all_ profiles that are
> available on the system rather than just the ones in the current profile.
> I don't know how well this would work with lots (100's) of profiles?

I thought we could use a single XML tree, regrouping all the profiles
fragment required to build the configuration we want.
The profile for a single package is usually quite small (< 1K),
so that a profile for a configuration containing 1000 packages
translates into less than 1Mo of XML text, which is probably doable,
even if the startup time wouldn't be blinding fast.

If you don't want to have an all-encompassing profile (which doesn't mean
a single file !), it is probably possible to use a "load-on-demand" mechanism
where you load the profile you need and graft it on the existing XML tree.
I don't know well libxml2 interface, but it should be possible with
making only quite localized modifications in nALFS code. 


> 
> > Of course, this simple algorithm requires that the processing of the
> > package is not too dependant on the context.
> > If we have:
> > 
> >    stage1
> >       package1
> >    stage2
> >      package2
> >        check package1
> > 
> > and if the stageinfo of stage1 and stage2 are different (e.g. chroot
> > to different directories), we cannot simply interpret package1 in the
> > context of package2  so that this situation should be avoided if
> > we want automatic build of the required package.
> > 
> > And of course, the dependence graph shouldn't contain cycles
> > (that are meaningless in this context but could crash the application)
> > 
> 
> Agreed.
> 
> > Vassili
> 
> -- http://www.linuxuk.org --------------------------------------
> - Jamie Bennett     - 18 St Peters Terrace - jamie at linuxuk.org -
> - Software Engineer - Lower Bristol Road   -                   -
> - PCP Microproducts - Bath, England        -                   -
> ----------------------------------------------------------------
> -- 
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe alfs-discuss' in the subject header of the message
> 
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list