moritzruth/void-packages
1
0
Fork 0
Code Releases Activity Actions 2

Remove xbps bins and lib. They are now handled in launchpad.

Browse source 
--HG--
extra : convert_revision : b86cccec88eb76aaf9d81570b73d5a0413de9565
This commit is contained in:
Juan RP 2009-08-18 16:29:22 +02:00
parent 2437f8d351
commit 2251cfdb20
53 changed files with 0 additions and 8691 deletions
Download patch file Download diff file Expand all files Collapse all files

105
doc/BINPKG_INFO
View file

@ -1,105 +0,0 @@
------------------------------------------------------------------------------
BRIEF INTRODUCTION
------------------------------------------------------------------------------
A binary package built with xbps is a normal tar(1) archive, compressed
with bzip2 and has the following structure:
Package metadata
-----------------
/INSTALL
/REMOVE
/files.plist
/props.plist
Package data
-----------------
/usr
/var
/etc
...
Metadata info is stored in the "/var/db/xbps/metadata/$pkgname"
directory and two files will be always be present: files.plist
and props.plist.
The files.plist file contains the list of files/links/dirs that package
will install, as well as SHA256 hashes for files.
The props.plist file contains package metadata properties and has the
following structure:
<dict>
<key>pkgname</key>
<string>foo</string>
<key>version</key>
<string>3.40</string>
<key>maintainer</key>
<string>The Master BOFH <bofh@baobab.org> </string>
<key>short_desc</key>
<string>Foo is a virtual package</string>
<key>long_desc</key>
<string>
Foo is a virtual package to show how the metadata props.plist file works
with xbps handling binary packages.</string>
<key>architecture</key>
<string>x86_64</string>
<key>installed_size</key>
<integer>500000</integer>
<key>configuration_files</key>
<array>
<string>/etc/foo.conf</string>
...
</array>
<key>run_depends</key>
<array>
<string>bofh-2.0</string>
<string>blab-1.1</string>
...
</array>
...
</dict>
The INSTALL/REMOVE executables allows you to trigger any action
at pre/post installation/removal of the binary package.
The package's dictionary will also be written into the repository's package
index file, that describes information about a binary package on it.
See the BINPKG_REPOSITORY file for more info about repositories.
------------------------------------------------------------------------------
HOW TO USE BINARY PACKAGES
------------------------------------------------------------------------------
To install binary packages, firstly a repository must be created as well as
some binary packages for it. The flow for this task is:
1- xbps-src install <package>
2- xbps-src build-pkg all [requires sudo access]
3- xbps-repo genindex $XBPS_PACKAGES
4- xbps-repo add $XBPS_PACKAGES
5- xbps-bin install -r /rootdir <package>
So the tasks are: install the package into destdir (and all its dependencies),
build the binary package from the required package, generate the repository
index, add the repository into the pool and install the binary package.
Please note that by default, the xbps-* utils accept the -r flag, to specify
the root directory for all operations, in that case the package will be
installed into <rootdir> and metadata files into <rootdir>/var/db/xbps.
Don't forget to set this flag if you aren't using xbps as the primary
package manager in your system, otherwise it could overwrite some files!
See the BINPKG_REPOSITORY file for more info about repositories for
binary packages or SRCPKG_INFO for source packages.
------------------------------------------------------------------------------
Juan Romero Pardines <xtraeme@gmail.com>

116
doc/BINPKG_REPOSITORY
View file

@ -1,116 +0,0 @@
------------------------------------------------------------------------------
BRIEF INTRODUCTION
------------------------------------------------------------------------------
A repository for binary packages contains the packages itself, and
an index file describing the information about available packages.
The structure for this file is just the same than the plist file used
to register installed packages, aka "an array of dictionaries" and
a "dictionary per package". Additional objects are added into the
main dictionary to specify more info, like:
- pkgindex-version: version used to build the index.
- location-local: local path to the repository.
- location-remote: remote URI repository.
- total-pkgs: total of number of available packages.
"location-local" will always be created, and it might be exported via
a remote location specified with "location-remote".
The package dictionary will be the same than the one available in
package's metadata directory "/var/db/xbps/metadata/$pkgname/props.plist",
but some additional objects are added to provide enough info for
the repository itself:
- filename: name (and path relative to current dir) for the binary
package.
- filename-sha256: SHA256 hash of the binary package.
Here's how the package index plist file shall look like in a repository:
<dict>
<key>pkgindex-version</key>
<string>1.0</string>
<key>location-local</key>
<string>/xbps/repo/local</string>
<key>location-remote</key>
<string>http://www.xbps-remote.org/repo/public</string>
<key>total-pkgs</key>
<integer>666</integer>
<key>available-packages</key>
<array>
<dict>
<key>pkgname</key>
<string>klibc</string>
<key>version</key>
<string>1.5.17</string>
<key>filename</key>
<string>klibc-1.5.17.x86_64.xbps</string>
<key>filename-sha256</key>
<string>7b0de0521983037107cc33f2b1514126432f86ac2be1ef9b9dc51a1e959ea777</string>
<key>architecture</key>
<string>x86_64</string>
<key>installed_size</key>
<integer>9471141</integer>
<key>maintainer</key>
<string>Juan RP xtraeme@gmail.com</string>
<key>short_desc</key>
<string>Minimal libc subset for use with initramfs</key>
<key>long_desc</key>
<string>
klibc is intended to be a minimalistic libc subset for use with initramfs.
It is deliberately written for small size, minimal entanglement, and
portability, not speed. It is definitely a work in progress and a lot of
things are still missing.</string>
...
</dict>
...
</array>
</dict>
------------------------------------------------------------------------------
HOW TO USE BINPKGS WITH REPOSITORIES
------------------------------------------------------------------------------
To build binary packages from all currently installed packages in
XBPS_MASTERDIR:
$ xbps-src build-pkg all
To generate the repository package index for your $XBPS_PACKAGESDIR
setting in the configuration file:
$ xbps-repo genindex /path/to/dir
After this you can add your own local repository with binary packages:
$ xbps-repo add /path/to/dir
Added repository at /path/to/dir (1.0) with 6 packages.
$
Once it's registered, you can start searching/installing/removing
binary packages. You can add multiple repositories, the order for searching
is the same than they were added; check it with:
$ xbps-repo list
/storage/xbps/binpkgs
/path/to/dir
$
The first repository that has the metadata for a package wins, if not found
it will search in all them until it's found. A repository can also be
unregistered from the pool:
$ xbps-repo remove /path/to/dir
To show information about available packages in the repository pool:
$ xbps-repo show package
To search for binary packages by specifying a string:
$ xbps-repo search mypkg
------------------------------------------------------------------------------
Juan Romero Pardines <xtraeme@gmail.com>

36
doc/FEATURES
View file

@ -1,36 +0,0 @@
This is the incomplete list of currently implemented features:
* Packages are built from sources in a chroot, thus avoiding dependency
incompatibilities with installed system.
* Automatic compression of manual pages.
* Automatic compression of info files.
* Registers and unregisters info files automatically.
* Registers and unregisters shells in /etc/shells automatically.
* Binary package hash is checked before installing with SHA256 algorithm.
* Before removing a package, the hash of installed files is checked
to found modified files and ignores them if they were modified.
* Configuration files are preserved if they are modified.
* Support for multiple binary local package repositories.
* Support for running a script at pre/post install/remove in binpkgs.
* Support for running triggers at pre/post install/remove in binpkgs.
* Finds and removes orphan packages, i.e packages that were installed
automatically (required by some other package that was installed but
any package currently depends on).
* Show properties of available packages in repositories, as well as
installed. Like dependencies, installed size, binary package size,
configuration files, description, etc.
* Listing of files for binary packages, plus a flag is used to check
the SHA256 hash of any file in a package while listing them.

68
doc/README
View file

@ -1,68 +0,0 @@
-----------------------------------------------------------------------------
WHAT IS IT?
-----------------------------------------------------------------------------
xbps - xtraeme's build package system.
It is a simple build package system that installs packages inside of
a chroot in a destination directory. Once the package has been installed
into this directory, you can make it appear/unappear at the master directory
at any time. It's in spirit the same than GNU stow, but the files are just
copied (there are no soft/hard links).
xbps has been designed for Linux, and for the moment I'm not interested to
make it work on any other random OS. I've been a NetBSD developer for some
years and I do not want to come back... also the experience has helped to
me to start xbps and not to use pkgsrc, which is very portable but also
not so fast.
-----------------------------------------------------------------------------
REQUIREMENTS
-----------------------------------------------------------------------------
xbps uses proplib, a property container object library and it's almost the
same one available for NetBSD. Be sure to have it installed before using
xbps. You can get it at:
http://code.google.com/p/portableproplib/
I'm also the human maintaining the portable proplib package. I'd suggest you
to install it into /usr/local to avoid issues with your distribution packages.
Additionally the following software is required to be able to build and install
xbps binary/source packages:
* GNU GCC C++
* GNU Make
* fakeroot
* wget
* libarchive (development package)
* perl
* sudo
Super-user privileges are required as well, because all packages are built
in a chroot (except the ones that are included in a virtual package to be
able to build a minimal system for the chroot).
PLEASE NOTE THAT fakechroot or fakeroot-ng DO NOT WORK.
------------------------------------------------------------------------------
HOW TO USE IT
------------------------------------------------------------------------------
Before using xbps, some required utilities need to be built and installed
into $(PREFIX); by default they are installed into /usr/local.
You can do this by issuing "make" and "make install" as root in the top
level directory. See the REQUIREMENTS section above for required packages.
Once the xbps distfiles are installed into prefix, you can start building
packages from source, add local repositories with binary packages, install or
remove them, etc.
If you are only interested in building/using packages from source, see the
SRCPKG_INFO file.
For information about binary packages, see the BINPKG_INFO file.
------------------------------------------------------------------------------
Juan Romero Pardines <xtraeme@gmail.com>

110
doc/SRCPKG_INFO
View file

@ -1,110 +0,0 @@
-----------------------------------------------------------------------------
REQUIREMENTS
-----------------------------------------------------------------------------
To be able to build packages from source the following software is required
in the host system:
* GNU GCC C++
* GNU Make
* fakeroot
* wget
* libarchive (development package)
* perl
* sudo
Super-user privileges are required as well, because all packages are built
in a chroot (except the ones that are included in a virtual package to be
able to build a minimal system for the chroot).
------------------------------------------------------------------------------
HOW TO BUILD/HANDLE PACKAGES FROM SOURCE
------------------------------------------------------------------------------
Before using xbps-src, some required utilities need to be built and installed
into $(PREFIX); by default they are installed into /usr/local.
You can do this by issuing "make" and "make install" as root in the top
level directory.
If configuration file is not specified from the command line with the
-c flag, it will first try to use the default location at
/usr/local/etc/xbps.conf (or the installation prefix that was specified
to the make(1) command), and as last resort in the etc directory of the
current directory.
To avoid problems with libtool and configure scripts finding stuff that is
available in the host system, almost all packages must be built inside of a
chroot. So the first thing would be to create the binary packages with:
$ xbps-src install xbps-base-chroot
This will build all required packages via fakeroot in masterdir, therefore you
can run it as normal user. Next commands will require super-user privileges
and all package handling will be done within the chroot. I believe it's the
most easier and faster way to handle clean dependencies; another reason would
be that xbps packages are meant to be used in a system and not just for
ordinary users. So once all packages are built, you can create and enter
to the chroot with:
$ sudo xbps-src chroot
Press Control + D to exit from the chroot. The following targets will require
to be done in the chroot:
build, configure, install, install-destdir, remove, stow and unstow.
Now let's explain some more about the targets that you can use. To start
installing packages you should use the install target:
$ sudo xbps-src install glib
If the package is properly installed, it will be "stowned" automatically.
``stowned´´ means that this package is available in the master directory,
on which xpbs has copied all files from DESTDIR/<pkgname>.
To remove a currently installed (and stowned) package, you can use:
$ sudo xbps-src remove glib
Please note that when you remove it, the package will also be removed
from XBPS_DESTDIR and previously "unstowned".
To stow an already installed package (from XBPS_DESTDIR/<pkgname>):
$ sudo xbps-src stow glib
and to unstow an already installed (stowned) package:
$ sudo xbps-src unstow glib
You can also print some stuff about any template build file, e.g:
$ xbps-src info glib
To list installed (stowned) packages, use this:
$ xbps-src list
To only extract the distfiles, without configuring/building/installing:
$ xbps-src extract foo
To not remove the build directory after successful installation:
$ sudo xbps-src -C install blah
To only fetch the distfile:
$ xbps-src fetch blah
To only install the package, _without_ stowning it into the master directory:
$ sudo xbps-src install-destdir blob
To list files installed by a package, note that package must be installed
into destination directory first:
$ xbps-src listfiles blob
------------------------------------------------------------------------------
Juan Romero Pardines <xtraeme@gmail.com>

46
doc/TODO
View file

@ -1,46 +0,0 @@
xbps-src:
* Personalized scripts per template to unpack distfiles.
* Multiple URLs to download source distribution files, aliases, etc.
Something like ${sourceforge} to pick up any specified mirror on the list.
* Fix -C flag while building packages via chroot.
Packages:
* Create /etc/issue.
* Add a trigger for fc-cache.
* Add a trigger to (un)register users/groups. Currently packages that
require user/groups use custom INSTALL/REMOVE scripts, which adds
a lot of duplicated work.
* Add support to stop and restart package's OpenRC service while
removing and upgrading a package.
[PARTIAL: at pre-remove the services are stopped but not yet restarted]
* How to handle kernel package upgrades? dpkg seems to keep previous
package and its initramfs, and a dummy package depends on the latest one.
I think this is the best option.
* Fix initramfs-tools trigger for $pkgname != kernel.
* Fix initramfs-tools 'update-initramfs -a'.
* Fix HAL/PolicyKit for nonroot to be able to admin tasks.
* Fix loadkeys(1) incorrectly loading the olpc keymap vs qwerty.
xbps-bin:
* Add support to install binary packages without any repository.
* Add a flag to reinstall a package version that is already installed,
overwritting files on disk and updating required_by if required.
Perhaps change the automatic-install object to false, like pkg_install
from NetBSD do.
* Implement shell style match patterns with fnmatch() for install, update
and remove.
* Make -f flag to overwrite files when installing, and to ignore
files with wrong checksum or unexistent when removing.
[PARTIAL: only unexistent files are ignored when removing]
libxbps:
* Add support to upgrade packages but overwritting current files;
this will fix libc, sh and others. An "essential" boolean obj
seems to be a good way to find such packages, like dpkg.
[PARTIAL: files are overwritten but obsolete files are not
taken into account yet]
xbps-repo:
* Add support to add only specified packages, rather than looking
at all files in a directory.
* Add support for remote repositories, requires libfetch.