Package Management Options

I've been thinking about how the paco patch is currently
managed and
was trying to think how package management could be more
general in
jhalfs. Unfortunately, my understanding of xsl sucks. Maybe
you could
point me in the right direction on my thoughts.

What I was thinking was that commands that install to the
root
filesystem in LFS always be defined with a role, such as
"install".
So, you could then have something like:

<screen role="install"><userinput>make
install</userinput></screen>

Then, during the command extraction during jhalfs, you could
query for
this role and define extra <xsl:text> actions that
surround this text.
This is really no different than what the paco patch appears
to be
doing now, except it's not hardcoding things by looking for
string().

Now, here's where I'm totally lost by not knowing xsl. I'd
like it if
the lfs.xsl script "included" something like
pm.xsl where you could
define custom actions that would be triggered for the
"install" role.
Basically, I think it would be preferable if the dumped
commands
contained all the extra processing instead of mangling
LFS/master.sh
to add commands to the Makefile.

Is this possible?

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

Dan Nicholson wrote:
> I've been thinking about how the paco patch is
currently managed and
> was trying to think how package management could be
more general in
> jhalfs. Unfortunately, my understanding of xsl sucks.
Maybe you could
> point me in the right direction on my thoughts.
> 
> What I was thinking was that commands that install to
the root
> filesystem in LFS always be defined with a role, such
as "install".
> So, you could then have something like:
> 
> <screen
role="install"><userinput>make
install</userinput></screen>
> 
> Then, during the command extraction during jhalfs, you
could query for
> this role and define extra <xsl:text> actions
that surround this text.
> This is really no different than what the paco patch
appears to be
> doing now, except it's not hardcoding things by looking
for string().
> 
> Now, here's where I'm totally lost by not knowing xsl.
I'd like it if
> the lfs.xsl script "included" something like
pm.xsl where you could
> define custom actions that would be triggered for the
"install" role.
> Basically, I think it would be preferable if the dumped
commands
> contained all the extra processing instead of mangling
LFS/master.sh
> to add commands to the Makefile.
> 
> Is this possible?

   Anything is possible the question is: "Should we
commit 
time/resources to hardwiring a pm into JHALFS"
   I do not believe the use of package manager to install
the books is 
proper for JHALFS. 'Hard wiring' a package manager moves
jhalfs one step 
closer to be a full blown distro manager and one step away
from a pure 
book tool.
> 
> -- 
> Dan

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Martes, 17 de Octubre de 2006 20:00, Dan Nicholson
escribió:
> I've been thinking about how the paco patch is
currently managed and
> was trying to think how package management could be
more general in
> jhalfs. Unfortunately, my understanding of xsl sucks.
Maybe you could
> point me in the right direction on my thoughts.
>
> What I was thinking was that commands that install to
the root
> filesystem in LFS always be defined with a role, such
as "install".
> So, you could then have something like:
>
> <screen
role="install"><userinput>make
install</userinput></screen>

Well, to be actually useful a package management support
should be availlable 
while building BLFS packages.

Now think on how the BLFS XML layout will need be changed to
add something 
like the above. That could require be done not only on
"make install" 
commands, but also to each "mv ..", "ln
..", "cat ...", etc. to can track 
acuratelly all installed files.

> Then, during the command extraction during jhalfs, you
could query for
> this role and define extra <xsl:text> actions
that surround this text.
> This is really no different than what the paco patch
appears to be
> doing now, except it's not hardcoding things by looking
for string().

Yes, in theory that is a good method, not only for PM but
also for other stuff 
and customizations.. But that implies that all book's
sources will need be 
redone thinking on atomatization.

> Now, here's where I'm totally lost by not knowing xsl.
I'd like it if
> the lfs.xsl script "included" something like
pm.xsl where you could
> define custom actions that would be triggered for the
"install" role.
> Basically, I think it would be preferable if the dumped
commands
> contained all the extra processing instead of mangling
LFS/master.sh
> to add commands to the Makefile.
>
> Is this possible?

For example, in LFS, for the unpack code we need to know
what package nane is 
associated with each XML page. 

At bash level is easy to grep a packages list searching what
package match a 
script filename.

At XSL level I can't find yet an easy way to do that. Maybe
that could be 
implemented via key() and document() functions. The easiest
way is to add the 
package name to the XML file that build it, like in BLFS.
But again, that 
meant to change the book sources thinking on automatization.

At this moment we are working on a way to allow user to full
customize the 
{C,H}LFS builds (BLFS builds are full customizables by
default). 

The preliminar code to create configuration files and
install additional 
packages after installing the base system (like packages
required to acces 
the network or to support specific hardware) is in trunk.

Remain to allow to customize the base system packages. For
example, to change 
a package version, to add extra patches, to replace one
package by other 
(GRUB by LiLo, SysVinit by depinit, etc), or to insert new
packages, like the 
one needed for the PM of choice, without having to edit a
local book sources 
working copy.

When having that ready, a user will be able to hack the
build in any way it 
would, included package management support. Of course, only
"by the book" 
builds plus the current implemented desviations (ICA/farce
and optimizations 
support) will be full automatized. The others hacks will
need be made "from 
scratch" editing shell script files and makefiles, but
after all this is the 
philosophy of LFS world 

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 10/17/06, George Boudreau <georgeblinuxfromscratch.org> wrote:
>
>    Anything is possible the question is: "Should
we commit
> time/resources to hardwiring a pm into JHALFS"
>    I do not believe the use of package manager to
install the books is
> proper for JHALFS. 'Hard wiring' a package manager
moves jhalfs one step
> closer to be a full blown distro manager and one step
away from a pure
> book tool.

Actually, what drove me writing that is a desire to _not_
hardwire a
pm into jhalfs, but make it more generic. The paco patch
shows that
you have to do a lot of mangling of jhalfs internals to get
it
working. I would like this to be more plugin like.

What I'm proposing is that there is a generic pm.xsl that is
initially
empty. I.e., in the default case, nothing happens. You can
fill in the
details yourself. Ideally, only this one file would need to
be edited
to add support for <your package manager>.

Now I'm going to read Manuel's post to see if my XSL musings
are crack.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 10/17/06, M.Canales.es <manuellinuxfromscratch.org>
wrote:
> El Martes, 17 de Octubre de 2006 20:00, Dan Nicholson
escribió:
>
> > Then, during the command extraction during jhalfs,
you could query for
> > this role and define extra <xsl:text>
actions that surround this text.
> > This is really no different than what the paco
patch appears to be
> > doing now, except it's not hardcoding things by
looking for string().
>
> Yes, in theory that is a good method, not only for PM
but also for other stuff
> and customizations.. But that implies that all book's
sources will need be
> redone thinking on atomatization.

Maybe I'm in the minority, but I think that's a useful goal.
To me, it
seems like most of the editors are just following XSL
convention
anyway. I.e., in BLFS we're adding role="root"
because somebody said
to do it. If we were to start saying add
role="install" and did the
initial mass changeover, I don't think anyone would have too
big a
problem.

> > Now, here's where I'm totally lost by not knowing
xsl. I'd like it if
> > the lfs.xsl script "included" something
like pm.xsl where you could
> > define custom actions that would be triggered for
the "install" role.
> > Basically, I think it would be preferable if the
dumped commands
> > contained all the extra processing instead of
mangling LFS/master.sh
> > to add commands to the Makefile.
> >
> > Is this possible?
>
> For example, in LFS, for the unpack code we need to
know what package nane is
> associated with each XML page.
>
> At bash level is easy to grep a packages list searching
what package match a
> script filename.
>
> At XSL level I can't find yet an easy way to do that.
Maybe that could be
> implemented via key() and document() functions. The
easiest way is to add the
> package name to the XML file that build it, like in
BLFS. But again, that
> meant to change the book sources thinking on
automatization.

Could you point me to some XSL documentation? Maybe some
newbie level
stuff, too? This is my major stumbling block in mapping
between book
and build. You guys are doing kick ass work on jhalfs, but I
think
there's some lower level work that could be done to make it
more
powerful without requiring lots of workarounds at the higher
level.

Thanks.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

Dan Nicholson wrote:
...
> What I'm proposing is that there is a generic pm.xsl
that is initially
> empty. I.e., in the default case, nothing happens. You
can fill in the
> details yourself. Ideally, only this one file would
need to be edited
> to add support for <your package manager>.
>

I hope I'm not out-of-line [contributing] here but,
personally, I'd like 
to see jhalfs (or it's sibling?) develop so it has an
architecture that 
supports a "plugin" facility. The idea being that
anyone can develop new 
or innovative features without having to change the base
code which 
builds THE BOOK. I'm sure something could be done, even in
bash, to 
allow this sort of flexibility?

I think the ability to build {L,C,H,B}FS using this tool is
terrific and 
it has proven to be a very useful tool (Take the ICA/farce
additions or 
the PACO patch) so why not try and make a platform which
would allow 
individual customisations?

I am not a software engineer, but have "played"
with writing code in 
Basic (& VB), Java, PHP, and bash etc... It would be
really great if 
anyone could contribute add-on features that could be
developed to a 
standardised specification.

Thanks anyway. I love the LFS project and I have some
business goals to 
develop a platform based around LFS and gladly offer my
assistance in 
whatever way is appropriate.

Alan
LFS id: 213 (I think)

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Martes, 17 de Octubre de 2006 23:08, Dan Nicholson
escribió:

>
> Maybe I'm in the minority, but I think that's a useful
goal. To me, it
> seems like most of the editors are just following XSL
convention
> anyway. I.e., in BLFS we're adding
role="root" because somebody said
> to do it. If we were to start saying add
role="install" and did the
> initial mass changeover, I don't think anyone would
have too big a
> problem.

The basic problem is to develop the XML tags+attributes
framework that would 
allow to extract the commands and packages info separated by
type, without 
breaking validation and/or HTML/PDF output.

Then show it to all books editors and hope that they agree
with implementing 
the changes.

The first point requires time to find a working and
editor-friendly solution. 
The second point is an unknown variable and may depend on
who and when the 
proposal is made.

> Could you point me to some XSL documentation? Maybe
some newbie level
> stuff, too? This is my major stumbling block in mapping
between book
> and build. You guys are doing kick ass work on jhalfs,
but I think
> there's some lower level work that could be done to
make it more
> powerful without requiring lots of workarounds at the
higher level.

Well, I learn XSL/Xpath/Xpointer/CSS reading the W3C
specifications and 
playing with the DocBook XSl code and books sources.

I don't have in my bookmarks links to XSL manuals, but a
quick search sow this 
ones:

http:/
/ils.unc.edu/~pottl/inls259/xml/xsl.html
http://www.quepublishing.com/articles/article.
asp?p=26312&rl=1
http://pub
lib.boulder.ibm.com/infocenter/wsphelp/topic/com.ibm.etools.
xsl.source.doc/tasks/tcrtxsl.htm


-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page