Re: New tazpkg installs busybox-pam for tazpkg

[Julien Rabier <taziden@xxxxxxxxxx>]

There is another thing to take into account : compress/uncompress time.
Do you have stats about this ?

Julien

Le 12 déc. à 12:53, Christopher Rogers a écrit :
>    I found out that 7z is better then lzma and xz.
> 
>    size in pcmanfm:
>    VirtualBox-3.2.10-OSE.tar.bz2    58.2MB
>    VirtualBox-3.2.10-OSE.tar.xz      42.8MB
>    VirtualBox-3.2.10-OSE.tar.lzma  42.5MB
>    VirtualBox-3.2.10-OSE.7z           39.8MB
> 
>    I used p7zip for this. It would add 252kb to iso though. So what are your
>    thoughts on this development?
> 
>    On Sat, Dec 11, 2010 at 11:05 PM, Christopher Rogers
>    <slaxemulator@xxxxxxxxx> wrote:
> 
>      I'm also thinking (cause of new hosting for tank soon) that when we use
>      your new tazwok that we should delete $WOK/$PACKAGE/$PACKAGE-$VERSION
>      folder. But will have to added option that can be enabled in receipt
>      called like KEEP_SOURCE="yes". This will be need in since cause some
>      packages get stuff still in source folder.
> 
>      This is just a thought.
> 
>      On Sat, Dec 11, 2010 at 9:57 PM, GoKhlaYeh <gokhlayeh@xxxxxxxxxx> wrote:
> 
>        On Fri, 10 Dec 2010 23:20:45 +0300
>        Alexander Medvedev <devl547@xxxxxxxxx> wrote:
> 
>        > Looks like we need to create wok-experimental [?]
>        > There are lots of interesting features and tweaks to try, but
>        currently we
>        > are bound to compatibility with standart repos and software.
>        >
>        > Does anyone except Chris interested in tweaking SliTaz?
> 
>        Using a wok-experimental is a good idea.
> 
>        The goal here is making receipts writing more light and simple
>        (KISS...); About that point, I just discover that pathes setted in
>        configure (--prefix= and that sort of things) can be setted globally
>        in a config.site script. After some tests it appears to works well;
>        but I found some papers which warning about the facts that it doesn't
>        works with each code source (depending on the version of autoconf used
>        before generating the tarball).
> 
>        In conclusion for most receipts (theorically) it's possible to have
>        compiles_rules looking like :
>        compile_rules()
>        {
>               cd $src
>               ./configure && make && make install
>        }
> 
>        instead of :
> 
>        compile_rules()
>        {
>               cd $src
>               ./configure \
>                       --prefix=/usr \
>                       --infodir=/usr/share/info \
>                       --mandir=/usr/share/man \
>                       $CONFIGURE_ARGS &&
>               make -j 4 && make DESTDIR=$PWD/_pkg install
>        }
> 
>        Actually on tested packages it works well. What I'm going to do now is
>        ensure that's fully backward compatible using tweaks like the one
>        Christopher suggest. The general rules is : using global setting only
>        when it's not set in the receipt; else, use current behavior. This way
>        we will have all our time to apply the changes in the wok.
>        --
>        GoKhlaYeh <gokhlayeh@xxxxxxxxxx>
> 
>        ---
>        SliTaz GNU/Linux Mailing list - http://www.slitaz.org/

Attachment: signature.asc
Description: Digital signature