src2pkg-2.9 - build .pets from source code!

[01micko]

I have a bug to report.

I know you don't like the .pet package format and have talked about dropping it. If you don't then there is a bug with the package naming in the pet.specs file.

sdl-1.2.14|sdl|1.2.14|1|BuildingBlock|596K|pet_packages-14.0|sdl-1.2.14-1.pet|unknown|No summary text for sdl|slackware|14.0||

The bold part misses the arch which does exist in the package name. I used splitting;

Code: Select all

src2pkg --splitpkg=devel,doc,nls --jobs=6 -PET2 -CWD SDL-1.2.14.tar.xz --arch=i486 -A

Also, all 3 packages contain a populated usr/doc directory.

Other than that it seems all patches were applied fine and the package works fine.

BTW, SFR found the fullscreen patch see here

Here is the generated build script:

Code: Select all

#!/bin/bash
## src2pkg script for: 	sdl
## Auto-generated by src2pkg-2.91
## src2pkg - Copyright 2005-2013 Gilbert Ashley <amigo@ibilio.org>

SOURCE_NAME='SDL-1.2.14.tar.xz'
ALT_NAME='sdl'
VERSION='1.2.14'   # Use ALT_VERSION to override guessed value
# ARCH=''
# BUILD='1'
# PRE_FIX='usr'
# Any extra options go here:
# EXTRA_CONFIGS=""
PATCHLIST='fullscreen-sdl-1.2.14.patch.gz
sdl-1.2.14-fix-mouse-clicking.patch.gz
sdl.linux-2.6.31.input_absinfo.diff.gz'
MAKE_COMMAND='make -j6'

# Optional function replaces configure_source, compile_source, fake_install
# To use, uncomment and write/paste CODE between the {} brackets.
# build() { CODE }

# Get the functions and configs
. /usr/libexec/src2pkg/FUNCTIONS ;

# Execute the named packaging steps:
pre_process
find_source
make_dirs
unpack_source
fix_source_perms
configure_source #
compile_source   # If used, the 'build' function replaces these 3
fake_install     #
fix_pkg_perms
strip_bins
create_docs
compress_man_pages
make_description
make_doinst
make_package
post_process

## See the documentation for more help and examples. Below are some of
# the most common Extras and Options for easy cut-and-paste use.
# DOCLIST='' PATCHLIST='' INSTALL_TYPE=''
# CONFIG_COMMAND='' MAKE_COMMAND='' INSTALL_LINE='' 
# When editing src2pkg scripts to add custom code, use these variables
# to refer to the current directory, the sources or the package tree:
# $CWD (current directory), $SRC_DIR (sources), $PKG_DIR (package tree)
# Other commonly-used directories include: $DOC_DIR (document directory)
# $MAN_DIR (man-page directory) $DATA_DIR (shared-data directory)

[amigo]

Thanks for reporting, micko. I don't recall seeing any pets which have the arch in them. Is this something new?

As for the docs, the content in split packages is usually not the same. Any redundant items will simply overwrite existing items. The fact that docs are not completely separated is owing to a principle: when distributing packages built from open source sources, the license should always be in there.

NLS packages may, or may not, contain binary content, depending on how you define 'binary'. To be on the safe side I have src2pkg include docs with nls packages.

devel packages contain the license and other general docs, plus any *.info and *.man pages which relate to the development parts of the package (man2 and man3).

Sometimes the content of usr/doc will be the same across all split packages -when there is only a README and LICENSE, for instance.

Docs are particularly hard to split in an intelligent way. If you try to always spit the docs you wind up with lots of tiny docs packages which only contain a couple of files. Because of this I created the DOC_SPLIT_SIZE setting, which sets a low-side size limit. The default is 100K, which means that if the doc dir contains less than 100K of docs the routine will not create a docs package even though you have asked for it.

A very long time ago, I built in the option to minimize the size of the docs, by setting DOCLIST=MINIMAL. You may wish to try that and skip splitting the docs.

I try to be helpful about creating or modifying options to fit real-life needs, but I have always refused to have src2pkg simply delete all docs from packages. I simply don't believe it is the right thing to do. I really am worse than debian on this. For debian packages, they don't ship them with a copy of the license for each package. Instead, all packages rely on a common-licenses package which contains a copy of all the common open-sources licenses. Documentation in the package (copyright and control files) refer to the relevant license. But, this means that a (sometimes) binary package has been distributed without including that license. I designed a routine which does it this way:
Each package contains a copy of its correct license -which is located in a common location(not in the package-specific doc dir)- so that each package will overwrite any existing copy of that license. The doc directory for the package then contains a symlink to that license. This means each package still contains a copy of the license, but since it is a copy which overwrites the common location, on an installed system you only have one copy of each license instead of a identical copy in hundreds of dirs under /usr/doc.

Comments or questions are welcome.

[01micko]

Thanks for reporting, micko. I don't recall seeing any pets which have the arch in them. Is this something new?

.. no not new just not widely used. In woof-CE the 'new2dir' script now gets arch from uname -m (as std in most package build scripts). Of course the disadvantage of new2dir is that it uses installwatch. I much prefer not to install when packaging. Unfortunately, not all sources support destdir so I take the lazy way out and use new2dir. Anyway, the packages of course all get correct naming, just the pet.specs may cause an issue with package management.

As for the docs, the content in split packages is usually not the same. Any redundant items will simply overwrite existing items. The fact that docs are not completely separated is owing to a principle: when distributing packages built from open source sources, the license should always be in there.

NLS packages may, or may not, contain binary content, depending on how you define 'binary'. To be on the safe side I have src2pkg include docs with nls packages.

devel packages contain the license and other general docs, plus any *.info and *.man pages which relate to the development parts of the package (man2 and man3).

Sometimes the content of usr/doc will be the same across all split packages -when there is only a README and LICENSE, for instance.

Docs are particularly hard to split in an intelligent way. If you try to always spit the docs you wind up with lots of tiny docs packages which only contain a couple of files. Because of this I created the DOC_SPLIT_SIZE setting, which sets a low-side size limit. The default is 100K, which means that if the doc dir contains less than 100K of docs the routine will not create a docs package even though you have asked for it.

A very long time ago, I built in the option to minimize the size of the docs, by setting DOCLIST=MINIMAL. You may wish to try that and skip splitting the docs.

I try to be helpful about creating or modifying options to fit real-life needs, but I have always refused to have src2pkg simply delete all docs from packages. I simply don't believe it is the right thing to do. I really am worse than debian on this. For debian packages, they don't ship them with a copy of the license for each package. Instead, all packages rely on a common-licenses package which contains a copy of all the common open-sources licenses. Documentation in the package (copyright and control files) refer to the relevant license. But, this means that a (sometimes) binary package has been distributed without including that license. I designed a routine which does it this way:
Each package contains a copy of its correct license -which is located in a common location(not in the package-specific doc dir)- so that each package will overwrite any existing copy of that license. The doc directory for the package then contains a symlink to that license. This means each package still contains a copy of the license, but since it is a copy which overwrites the common location, on an installed system you only have one copy of each license instead of a identical copy in hundreds of dirs under /usr/doc.

Comments or questions are welcome.

Thanks for your detailed explanation and after absorbing it makes sense to not split off the docs. I will try soon DOCLIST=MINIMAL.

BTW, is there any way to combine sources into one package? SDL is a classic example where the SlackBuild bundles into the base sdl package sdl-mixer, sdl-image, sdl-net, sdl-ttf,

Thanks.

[amigo]

"pet.specs may cause an issue with package management" Can you confirm whether that is the case with pets which include the 'arch'?

It is possible to build multiple sources into a single package, but src2pkg doesn't make this any easier than regular slackbuilds -at least not now. I have done some work on making this easeir, but requires major re-writing of parts of src2pkg. The idea is certainly relevant and I'm thinking lots about it as I consider re-writing much of src2pkg from scratch. I'll probably end up breaking backwards-compatibility -the 'API' for the build scripts would need to change bigtime.

Here's an example script which combines multiple sources:
http://distro.ibiblio.org/amigolinux/di ... ng.src2pkg

For stuff which is easily built and has a well-defined relationship with 'main' sources, I prefer to have separate packages. If one supposes that dependency resolution works correctly, this poses no problem. Combining packages sounds like a good idea, but isn't one. Again, if dep-resolution works, a 'meta' package could be used -that is a package which doesn't include any real content, it simply depends on the various individual packages meant to be grouped. This allows for more flexible usage.

I do find it odd that the users of a decidedly-small-size distro are the first to want to bundle lots of stuff together which other users may not need or want. for instance, someone here was working on a super-SFS which would contain all script interpretors like lua, python, perl -and while we're at it throw in QT4 & CO.? As if those things were related at all. Say I want lua which needs a few MB itself -but perl needs 25MB and python even more -all of a sudden we have a 100MB package. It is annoying to have a long list of installed packages when each are properly separate, but it gets even worse when you start splitting packages -suddenly for each unit of functionality we have 4 packages. The last time I rebuilt my local system I split all packages, but I think I will only split devel content next time.