Tired of one dependency and then another
You might get tired of the dependency hell that happens when trying to install one thing only to find that something else must be installed first, and when trying to install that, more things, and so on ad nauseam.
There is a blfs-deps hint that was intended to take care of that for BLFS 5.0. Getting it to work for BLFS 6 and up requires an upgraded AuditPackages.py which I could only find embedded in this message in the blfs support mailing list. The structure of the xml files was completely changed for BLFS 6. Libxml2 must be installed after Python in order to get the python module libxml2.py that is required by the upgrade.
Another thing is the blfs-tool which was illustrated in Building BFLS packages with jhalfs. The blfs-tool is what you get if you unpack a jhalfs tarball like jhalfs-2.3.1.tar.bz2 and run make and select to use BOOK (Beyond Linux From Scratch). Then, the blfs-tool will be what exists in the blfs_root directory that gets created in your home directory. Then you go there and type "make" and it does what it does.
Before you could run the blfs-tool, though, you have to have installed subversion, libxml2, libxslt, and tidy, and docbook xml dtd, and docbook xsl stylesheets. The blfs-tool can calculate the installation in dependency order, but it is somewhat clumsy to use.
To get blfs-tool started for BLFS 6.3, you cd into the unpacked jhalfs-2.3.1 directory and type "make".
Say Use BOOK (Beyond Linux From Scratch)
Say Release (Branch or stable book)
Say (6.3/6.3/BOOK) Book Version (mandatory)
It will then use svn to download the xml files into blfs-xml in blfs_root in your homedir.
Then a screen comes up like you could start selecting packages, but don't do that!
Instead, select EXIT.
Select YES to save your new JHALFS configuration.
Then cd to blfs_root in you homedir and then type "make".
Both of those tools are very well done and are prime examples of efforts to further the cause of alfs.
But neither the blfs-deps hint nor the blfs-tool can handle perl modules, python modules, dbus bindings, or various other irregularities. Because of the irregularities in the xml files, any tool designed to assist with building has enormous challenges to face.
It would be possible to make all of the blfs xml files more friendly to extraction tools. For example, the multi-package xml files like perl modules, python modules, and dbus bindings could be split up so that each module would be in a separate file. Perhaps these are not deemed to be important enough. But, for example, you will have trouble building a full blown Gnome desktop without them.
The founder of Linux From Scratch, Gerard Beekmans, has said in an
interview:
"Teaching has always been the primary goal of LFS."
"But I think we also cannot ignore the automated process requirements anymore."
It is even stated on the alfs page:
"After having gone through the LFS and BLFS books more than 2 or 3 times, you will quickly appreciate the ability to automate the task of compiling the software you want for your systems."
Nevertheless, the argument that "you should do it by at least once by hand" seems to have thus far prevailed.
A NEW PROGRAM: pkgdeps
The pkgdeps program began as yet another attempt just to get a list of dependencies in build order before having some missing thing cause yet another ./configure command to bomb out -- or worse, to cause a compile to bomb out with no clue.
All of these tools ultimately rely on a copy of the blfs xml files.
Ideally, the blfs xml files could be located in the home dir.
If subversion is installed, the BLFS 6.3 xml files can be obtained with:
To see what other versions, you can browse in:
Or, the xml files can be obtained by running the blfs-tool if subversion, docbook, libxml2, libxslt, and tidy are installed.
OPERATION OF pkgdeps
The simplest operation is to list the dependency order:
pkgdeps pkg
Where pkg is the name of the xml file without the .xml extension.
For freetype, gtk+, and glib, you may need to stick a 2 at the end.
OPTIONS
REQUIRED:
pkg is the only required option. It must be the first option without a leading dash:
pkgdeps pkg
Experimentally, a list enclosed in quotes can count as first option:
pkgdeps "pkg1 pkg2"
OPTIONAL:
The directory location of the blfs xml files. If used it must be the second parameter without a leading dash:
pkgdeps pkg /my-blfs-xml
-alternat | -alternate | -alternates | -alternatives
List each pkgs dependencies to the side:
pkgdeps pkg -alternates
-one-level
Just see top level pkg on the command line and don't follow dependencies.
Possibly useful in combination with -alternatives:
pkgdeps "cairo pango" -one-level -alternate
-omit:
A colon delimited list of pkgs to intentionally ignore
pkgdeps gtk+2 -omit:libtiff:libxcb
-version
Display what package versions are in the book:
pkgdeps pkg -version
-show
Display whether a tracker* indicates that something is installed:
pkgdeps pkg -version -show
-show2
Like -show, but also display what version is installed, (according to a tracker* ):
pkgdeps pkg -version -show2
-needed
Display only the ones needing to be installed (based on the tracker* ):
pkgdeps pkg -version -show -needed
-time
Display about how long the install will take:
pkgdeps pkg -time
-size
Display approximate downloading size that may be required:
pkgdeps pkg -size
-required
Display just the required dependencies:
pkgdeps pkg -required
-optional
Display all the optional dependencies:
pkgdeps pkg -optional
The default is to check for required and recommended dependencies because the blfs book seems to warn that things built with just the required dependencies will build, but might not work.
-download
Display list of commands to download the files:
pkgdeps pkg -download
-download2
Display a list of all files to download (maybe hundreds):
pkgdeps pkg -download2
The option -download2 tries to behave differently than -download when the perl module/library LWP (libwww-perl) has been installed and there is an internet connection and the list of files includes xorg7. In that situation, it will read the blfs book's wget list(s) for xorg7 from the web and come up with a list of all the urls (300 +-100).
Because urls are very long, -download and -download2 suppress all other output except possibly a total time and total size.
A CONFIG FILE
If the directory location of the xml files is not specified on the command line, pkgdeps will try 2 things to estimate their location:
1 - There might be a /etc/pkgdeps.conf file having the location enclosed in <dir> tags like this: <dir> /here/they/are </dir>
2 - Failing that, it will try to find the unlikely file name desktop-file-utils.xml somewhere within the home directory.
Speaking of a potential /etc/pkgdeps.conf file:
The directory location of the xml files can be specified also like:
<dir>
~/blfs_root/blfs-xml
</dir>
A directory can be specified as a target to download files which gets shown by the -download and -download2 options when they show a download command that could be used. It is a display-only thing unless you actually execute the commands.
There can be an entry in /etc/pkgdeps.conf that looks like this:
<sources_dir>
/sources
</sources_dir>
or this:
<sources_dir>/sources</sources_dir>
Or, it could specify a different location e.g.
<sources_dir> /where_stuff_downloads </sources_dir>
* About that tracker
/var/lib/jhalfs/BLFS is the default tracking directory invented by jhalfs. The contents of the tracking directory is a collection of zero-length files that can get created with the touch command. Each of the files in the tracking directory should be named pkg-version for each package that was installed. The names of these files should usually be pretty much similar to the package name appearing in large, bold print on the page of the blfs book. If a package gets uninstalled and/or upgraded, then the file by the old name ought to be removed from the tracking directory also and, if appropriate, a new name should be added. If it gets all out of whack, well, you just fix it. If you absolutely know a package of a specific version is installed and yet it is not in the tracking dir, you can use the touch command to put it there. if you are sure, you fix it. If you don't keep track of what is installed by some method, it can be very difficult to determine whether a particular package of a particular version is installed. Sometimes package versions can be mixed and matched and sometimes they cannot, so it is better to play it safe and get it right.
The tracking directory is another thing that may appear in the potential /etc/pkgdeps.conf file like so:
<tracking_dir>
/var/lib/jhalfs/BLFS
</tracking_dir>
Of course it could be someplace else such as:
<tracking_dir> /here_is_what_is_installed </tracking_dir>
The name /var/lib/jhalfs/BLFS is just what the blfs-tool would use by default.
IRREGULARITIES
A short list of some irregularities/challenges that pkgdeps tries to handle:
- The pkg name might not match any xml file name.
- The pkg name might be a dbus-binding but all the dbus-bindings are in one xml file.
- The perl modules are all in one xml file and are too minimal and irregular.
- The python modules are all in one xml file and are irregular.
- The pkg name might be a gnome or kde meta-package.
- The meta-packages are different from anything else.
- Xorg7 packages have aliases with different aliases used in different places.
- x-window-system is a wild alias that throws everything off.
- Openoffice has to get at least 2 tarballs
- Must relent and pick all where dependencies are joined with complicated or/and.
- A dependency is sometimes a ulink instead of an xref
The previous post Cutting and pasting without looking has another perl program t-pl which gets the commands out of the xml files. It also has some tips on saving the script from the Google Docs.
There is a blfs-deps hint that was intended to take care of that for BLFS 5.0. Getting it to work for BLFS 6 and up requires an upgraded AuditPackages.py which I could only find embedded in this message in the blfs support mailing list. The structure of the xml files was completely changed for BLFS 6. Libxml2 must be installed after Python in order to get the python module libxml2.py that is required by the upgrade.
Another thing is the blfs-tool which was illustrated in Building BFLS packages with jhalfs. The blfs-tool is what you get if you unpack a jhalfs tarball like jhalfs-2.3.1.tar.bz2 and run make and select to use BOOK (Beyond Linux From Scratch). Then, the blfs-tool will be what exists in the blfs_root directory that gets created in your home directory. Then you go there and type "make" and it does what it does.
Before you could run the blfs-tool, though, you have to have installed subversion, libxml2, libxslt, and tidy, and docbook xml dtd, and docbook xsl stylesheets. The blfs-tool can calculate the installation in dependency order, but it is somewhat clumsy to use.
To get blfs-tool started for BLFS 6.3, you cd into the unpacked jhalfs-2.3.1 directory and type "make".
Say Use BOOK (Beyond Linux From Scratch)
Say Release (Branch or stable book)
Say (6.3/6.3/BOOK) Book Version (mandatory)
It will then use svn to download the xml files into blfs-xml in blfs_root in your homedir.
Then a screen comes up like you could start selecting packages, but don't do that!
Instead, select EXIT.
Select YES to save your new JHALFS configuration.
Then cd to blfs_root in you homedir and then type "make".
Both of those tools are very well done and are prime examples of efforts to further the cause of alfs.
But neither the blfs-deps hint nor the blfs-tool can handle perl modules, python modules, dbus bindings, or various other irregularities. Because of the irregularities in the xml files, any tool designed to assist with building has enormous challenges to face.
It would be possible to make all of the blfs xml files more friendly to extraction tools. For example, the multi-package xml files like perl modules, python modules, and dbus bindings could be split up so that each module would be in a separate file. Perhaps these are not deemed to be important enough. But, for example, you will have trouble building a full blown Gnome desktop without them.
The founder of Linux From Scratch, Gerard Beekmans, has said in an
interview:
"Teaching has always been the primary goal of LFS."
"But I think we also cannot ignore the automated process requirements anymore."
It is even stated on the alfs page:
"After having gone through the LFS and BLFS books more than 2 or 3 times, you will quickly appreciate the ability to automate the task of compiling the software you want for your systems."
Nevertheless, the argument that "you should do it by at least once by hand" seems to have thus far prevailed.
A NEW PROGRAM: pkgdeps
The pkgdeps program began as yet another attempt just to get a list of dependencies in build order before having some missing thing cause yet another ./configure command to bomb out -- or worse, to cause a compile to bomb out with no clue.
All of these tools ultimately rely on a copy of the blfs xml files.
Ideally, the blfs xml files could be located in the home dir.
If subversion is installed, the BLFS 6.3 xml files can be obtained with:
svn co svn://svn.linuxfromscratch.org/BLFS/tags/6.3/6.3/BOOK
To see what other versions, you can browse in:
svn ls svn://svn.linuxfromscratch.org/BLFS/tags
Or, the xml files can be obtained by running the blfs-tool if subversion, docbook, libxml2, libxslt, and tidy are installed.
OPERATION OF pkgdeps
The simplest operation is to list the dependency order:
pkgdeps pkg
Where pkg is the name of the xml file without the .xml extension.
For freetype, gtk+, and glib, you may need to stick a 2 at the end.
OPTIONS
REQUIRED:
pkg is the only required option. It must be the first option without a leading dash:
pkgdeps pkg
Experimentally, a list enclosed in quotes can count as first option:
pkgdeps "pkg1 pkg2"
OPTIONAL:
The directory location of the blfs xml files. If used it must be the second parameter without a leading dash:
pkgdeps pkg /my-blfs-xml
-alternat | -alternate | -alternates | -alternatives
List each pkgs dependencies to the side:
pkgdeps pkg -alternates
-one-level
Just see top level pkg on the command line and don't follow dependencies.
Possibly useful in combination with -alternatives:
pkgdeps "cairo pango" -one-level -alternate
-omit:
A colon delimited list of pkgs to intentionally ignore
pkgdeps gtk+2 -omit:libtiff:libxcb
-version
Display what package versions are in the book:
pkgdeps pkg -version
-show
Display whether a tracker* indicates that something is installed:
pkgdeps pkg -version -show
-show2
Like -show, but also display what version is installed, (according to a tracker* ):
pkgdeps pkg -version -show2
-needed
Display only the ones needing to be installed (based on the tracker* ):
pkgdeps pkg -version -show -needed
-time
Display about how long the install will take:
pkgdeps pkg -time
-size
Display approximate downloading size that may be required:
pkgdeps pkg -size
-required
Display just the required dependencies:
pkgdeps pkg -required
-optional
Display all the optional dependencies:
pkgdeps pkg -optional
The default is to check for required and recommended dependencies because the blfs book seems to warn that things built with just the required dependencies will build, but might not work.
-download
Display list of commands to download the files:
pkgdeps pkg -download
-download2
Display a list of all files to download (maybe hundreds):
pkgdeps pkg -download2
The option -download2 tries to behave differently than -download when the perl module/library LWP (libwww-perl) has been installed and there is an internet connection and the list of files includes xorg7. In that situation, it will read the blfs book's wget list(s) for xorg7 from the web and come up with a list of all the urls (300 +-100).
Because urls are very long, -download and -download2 suppress all other output except possibly a total time and total size.
A CONFIG FILE
If the directory location of the xml files is not specified on the command line, pkgdeps will try 2 things to estimate their location:
1 - There might be a /etc/pkgdeps.conf file having the location enclosed in <dir> tags like this: <dir> /here/they/are </dir>
2 - Failing that, it will try to find the unlikely file name desktop-file-utils.xml somewhere within the home directory.
Speaking of a potential /etc/pkgdeps.conf file:
The directory location of the xml files can be specified also like:
<dir>
~/blfs_root/blfs-xml
</dir>
A directory can be specified as a target to download files which gets shown by the -download and -download2 options when they show a download command that could be used. It is a display-only thing unless you actually execute the commands.
There can be an entry in /etc/pkgdeps.conf that looks like this:
<sources_dir>
/sources
</sources_dir>
or this:
<sources_dir>/sources</sources_dir>
Or, it could specify a different location e.g.
<sources_dir> /where_stuff_downloads </sources_dir>
* About that tracker
/var/lib/jhalfs/BLFS is the default tracking directory invented by jhalfs. The contents of the tracking directory is a collection of zero-length files that can get created with the touch command. Each of the files in the tracking directory should be named pkg-version for each package that was installed. The names of these files should usually be pretty much similar to the package name appearing in large, bold print on the page of the blfs book. If a package gets uninstalled and/or upgraded, then the file by the old name ought to be removed from the tracking directory also and, if appropriate, a new name should be added. If it gets all out of whack, well, you just fix it. If you absolutely know a package of a specific version is installed and yet it is not in the tracking dir, you can use the touch command to put it there. if you are sure, you fix it. If you don't keep track of what is installed by some method, it can be very difficult to determine whether a particular package of a particular version is installed. Sometimes package versions can be mixed and matched and sometimes they cannot, so it is better to play it safe and get it right.
The tracking directory is another thing that may appear in the potential /etc/pkgdeps.conf file like so:
<tracking_dir>
/var/lib/jhalfs/BLFS
</tracking_dir>
Of course it could be someplace else such as:
<tracking_dir> /here_is_what_is_installed </tracking_dir>
The name /var/lib/jhalfs/BLFS is just what the blfs-tool would use by default.
IRREGULARITIES
A short list of some irregularities/challenges that pkgdeps tries to handle:
- The pkg name might not match any xml file name.
- The pkg name might be a dbus-binding but all the dbus-bindings are in one xml file.
- The perl modules are all in one xml file and are too minimal and irregular.
- The python modules are all in one xml file and are irregular.
- The pkg name might be a gnome or kde meta-package.
- The meta-packages are different from anything else.
- Xorg7 packages have aliases with different aliases used in different places.
- x-window-system is a wild alias that throws everything off.
- Openoffice has to get at least 2 tarballs
- Must relent and pick all where dependencies are joined with complicated or/and.
- A dependency is sometimes a ulink instead of an xref
The previous post Cutting and pasting without looking has another perl program t-pl which gets the commands out of the xml files. It also has some tips on saving the script from the Google Docs.
posted by linux fan at
1:10 PM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
Click blog title for the latest post