Managing required packages in nALFS

Vassili Dzuba vassili.dzuba at wanadoo.fr
Fri Sep 13 08:49:06 PDT 2002


"Jamie Bennett" <jamie_bennett at pcpmicro.co.uk> a écrit dans le message de
news: 2130109F889CD5119FAD0050BA6F2D6B064AEC at SERVER...
> > -----Original Message-----
> > From: Vassili Dzuba [mailto:vassilidzuba at nerim.net]
> >
> > AFAIK, ALFS (if there is such a beast) does not provide any
> > mean to check the required
> > packages when building a new one. While it is not very
> > important when building a LFS,
> > which is a rather sequential process, it is more so when
> > building BLFS packages
> > as we are more likely in that case to build only some of
> > them, and in a random order.
> >
> > After having been bitten a few times, i patched nALFS to :
> >
> > - create a stamp file after a package has been build successfully
> > - provide a <check> element that allows to check if a given
> > stamp file exists,
> >   and interrupt the process if it does not
> > - provide a <stamp> element to build a stamp file outside of
> > a package,
> >   if needed.
> >
> > An example of use of <check>  is :
> >
> >     <package name="librep" version="&librep-version;">
> >
> >         <check>gmp</check>
> >         <check>gdbm</check>
> >
>
>   Just been thinking about this one as I'm half way through one of
> my own patches. What happens if for example gmp has its own
> dependencies? nALFS could complain that librep needs gmp but
> ideally it should complain that it needs gmp _and_ whatever
> gmp depends on.
>
>   This would require recursively traversing profiles which opens
> up a whole new can of worms :( I'm trying to have a go at this one
> but its not as easy as I first thought (or maybe I can't see the
> easy way of doing it).
>


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

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

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)

Vassili


> >Vassili Dzuba
>
> -- 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