paco-general — General

Re: [Paco-general] http:// and ftp:// support

[Thomas S. <to...@go...>]

Hi,
hmm, I`m using paco in a little different way.
Let me explain:
Updating a LFS-System is a special thing.
There a packages which are easy to update, other (like glibc, gcc or others) 
are a little bit complicated.
So we were thinking about how to do it a) clean, b) most automatically c) in 
an easy way.

A few years ago we (most work by my friend) started to write a script which do 
all this work,
the script is called "mkpacoball" and it is comparably with pacman from arch 
or pkgtools from Slackware.
It`s building pacoballs in a fakeroot-environment using a configuration-file 
in /etc and a Buildscript (PkgBuild) for each package.
mkpacoball is doing the following things:

It is reading the BuildScript (PkgBuild), creating a temp. Builddirectory 
under /tmp (Build-$$), it downloads the sources from the servers, extracts the 
sources and starts compiling the sources using the "nomal" Options  like --
prefix=/usr, sysconfdir=/etc, localstatedir=/var and so on.
Special Options can be defined in the PkgBuilds.

Maybe a package needs one or more patches the patchsource can be defined in 
the PkgBuild and mkpacoball patches them.

After compiling the sources mkpacoball installs the package to Destdir (under 
Build-$$), strips the binarys what can be enabled/disabled in /etc/mkpacoball) 
and at the end of all mkpacoball is asking for the root-Pwd to deinstall the 
old package and install the update. At least a pacoball will be generated from 
the installed files and will  be stored in a place you can define (take a look 
at the end of mkpacoball, Line 372).

What you need is mkpacoball, mkpacoball.conf (placed under /etc) and PkgBuilds 
for each Packages.

My PkgBuilds are sored under /usr/src/sources/$groups/$pkgname, as example

"/usr/src/sources/devel/boost/PkgBuild".

If there is a new version of boost I navigate to this PkgBuild, change the 
versionnumber in the PkgBuild and start building the package by
"mkpacoball -c -i PkgBuild". Setting an alias in the bashrc or zshenv is a 
good thing to make it easier :-)

mkpacoball depends on fakeroot, lzma/xz, wget, patch, tar, zip/unzip and a few 
other things which should be on each system.

Please let me say that this way of building packages is working here perfectly 
but updateing packages often uses new options and so on, use it on your own 
risk. Over the years I have written a Repo with more than 600 PkgBuilds but 
every toolchain is different. Because of this I do not attach all my 
PkgBuilds. Take a look at all the files, maybe you like it, maybe not :-)
But NO WARRANTY!!! Use it at your own risk!!!
 

If you have other questions about it please let me know, you can contact me 
here or with jabber (sla...@ja...).

Greetings








 





 




Am Donnerstag 03 Juni 2010, 09:30:53 schrieb Nathanael C Higley:
> Sorry about that last msg i forgot to turn off the encryption.
> 
> Well anyway i was wondering if there was any patch to paco-2.0.7
> with the lzma-xz.patch that would allow paco to download from and
> upgrade from http/ftp sites like the slackware-13.0 pkgtools or
> debpkg does?
> 
> ps: Thanks in advance
> 
> 
> ---------------------------------------------------------------------------
> --- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Paco-general mailing list
> Pac...@li...
> https://lists.sourceforge.net/lists/listinfo/paco-general

[Paco-general] http:// and ftp:// support

[Nathanael C H. <nat...@hu...>]

Sorry about that last msg i forgot to turn off the encryption.

Well anyway i was wondering if there was any patch to paco-2.0.7 
with the lzma-xz.patch that would allow paco to download from and 
upgrade from http/ftp sites like the slackware-13.0 pkgtools or 
debpkg does?

ps: Thanks in advance

[Paco-general] No subject

[Nathanael C H. <nat...@hu...>]

"Nathanael C Higley" <nat...@hu...> has sent you a secure email using Hushmail. To read it,
please visit the following web page:

	https://www.hushmail.com/express/JV5AH3A7



Frequently Asked Questions:


Why did I receive this email?

You have received this email because you have been sent a secure
email through Hushmail. To read your secure email, you must follow
the link provided and correctly answer a secret question chosen by
the sender.


What is a secure email?

Sending a regular email is like sending a postcard - it may be read
by any number of people before reaching its recipient(s). A secure
email is like sending a letter in a sealed envelope - it can only be
read by the sender and intended recipient(s).


Is it safe to follow the link in this email?

Yes, it is safe to visit the Hushmail web site by following the link
provided. However you should never open an email attachment unless 
you know the person who sent it to you, were expecting to receive 
the file from them, and have scanned the file for viruses.

When you arrive at the Hushmail web site, be sure to check the
following:

	The address bar of your web browser shows:
	https://www.hushmail.com/express

	A small picture of a padlock appears in the bottom right corner of
	your web browser

If you would prefer to access your message by entering its message
code, please visit the following web page:

	https://www.hushmail.com/express

You will be asked to enter the following message code: JV5A H3A7



What is Hushmail?

Hushmail is a web-based email service that lets you send and receive
email in total security using OpenPGP standard algorithms. These
algorithms, combined with Hushmail's unique key management system,
provide unrivalled levels of security. Hushmail's security is
end-to-end; when you send an email it is encrypted on your computer
and remains encrypted until it reaches its recipient(s). Hushmail's
encryption is automatic, transparent, and seamless - no special
computer skills are required.


How do I create a free Hushmail account?

You can create a free Hushmail account by clicking on the following
link: https://www.hushmail.com/?l=476

Re: [Paco-general] Paco with lzma-Support

[Nathanael H. <nat...@gm...>]

Info:

OK so I googled and it looks like the tar pkg got a few cosmetic
changes I wasn't aware of so here is the list from there page.

    * Support for xz compression (--xz option)
    * Short option -J is reassigned as a shortcut for --xz
    * The option -I is a shortcut for --use-compress-program
    * The --no-recursive option works with --incremental

So from the looks I'd say tar-1.22 and xz-4.999.9beta are the bare
minimum to get
paco-2.0.7 with lzma/xz patch to work.As for being able to test pkgs I
can make do using xz-utils

Fixed:

--->Everything is OK now I forgot to upgrade some of my pkgs<---
Sorry It was an error on my end

PS: Your patch works great now thanks a lot :)

Re: [Paco-general] Paco with lzma-Support

[Thomas S. <to...@go...>]

Am Samstag 12 September 2009 16:39:14 schrieb Nathanael Higley:
> Here are my results after testing the paco-2.0.7-lzma-xz.patch
> 

Hi,
I`m a little bit confused at this moment.
We`ve checked youre first problem (-ve) on 2 different machines (on my own and 
my friend tested it by himself).
pacoball -ve test.paco.tar.bz2 is extracting very well.
At this moment I have no idea what`s going wrong on your machine, sry.

The second problem:
It seems that -vt is creating a tar.bz2-archive and -t is not working for 
testing only.
Using -vt(x,z) is creating a lzma/xz-archive without any problems.

As example:

$paco -v tar   =>
 tar-1.22-2
and now:
$pacoball -vtx tar-1.22-2 -C /tmp   =>
/tmp/tar-1.22-2.paco.tar (1/1)
  100,0 %               254,4 KiB / 910,0 KiB = 0,280

The Result is a tar.xz-Archive.

And the same with only -vt:
$pacoball -vt tar-1.22-2 -C /tmp   =>
/tmp/tar-1.22-2.paco.tar:  3.394:1,  2.357 bits/byte, 70.54% saved, 931840 in, 
274549 out.

The Result is an tar.bz2-Archiv.

The problem seems to be that pacoball creates tar.bz2-Archives if using -vt 
without other options instaed of only testing.

O.K., sorry but I do not know what to say, here and on my friend`s machine 
everything is working well.
My OS:
An LFS-(SVN)-based System using glibc-2.10.1, Kernel 2.6.31 and gcc-4.4.1.

Greetiings




-- 
Feel free - "From Source"
www.linuxfromscratch.org 

Re: [Paco-general] Paco with lzma-Support

[Nathanael H. <nat...@gm...>]

Here are my results after testing the paco-2.0.7-lzma-xz.patch

Re: [Paco-general] Paco with lzma-Support

[Nathanael H. <nat...@gm...>]

Wow, Thanks Thomas S. I can't wait to tryout your patch and I really
appreciate u and ur friend taking the time to help on this and I'll
give it a try and tell ya if i run into any bugs or not.

[Sorry last msg got mangled]

PS: Please tell your friend I said thanks for the help

Re: [Paco-general] Paco with lzma-Support

[Thomas S. <to...@go...>]

Hi,
today I started writing a patch just for pacoball and later a friend finished 
the patch for paco/gpaco.
The Patch supports lzma and xz-utils.
Here everything is working well, please test the patch and let me know if 
somethings goes wrong.
Maybe the patch is interesting for a future version of paco?
Greetings,
Thomas

[Paco-general] Paco With LZMA Support

[Nathanael H. <nat...@gm...>]

Hi I would really like to see Paco with lzma support.
I've been using Paco for awhile and think it's one awesome source based
package organizer but I think the only drawback is that it is lacking
support for lzma compression and i would really be glad to see support for
this in the near future.
So if there is any possibility of this happening please if you don't mind
send me an e-mail.

PS:Thanks for any feedback and or help regarding this subject in advance

Re: [Paco-general] Patch for prefixing

[David R. <dav...@gm...>]

Hello Steven.

Thank you  very much for the patch. I will have a look at it when I find
some time, and eventually add it to the sources.

Cheers,

    ~David


2009/3/29 Steven Falken <bt...@go...>

> OOps, programmed in branch instead of trunk ...
> but now I made it still better :D
>
> On Sat, 2009-03-28 at 22:48 +0100, Steven Falken wrote:
> > Hi,
> > although there is often the possibility (in the installation procedure
> > of a tarballed program) to use make DESTDIR=/foobar to install a program
> > somewhere else, it doesn't exist (or even work) always. So I thought
> > about to do this via paco. I wrote some code and here it is. 'till now
> > there is no support for the paco/gpaco frontend; you have to do it the
> > old way LD_PRELOAD ....
> > Whats still needed? mkdir, mknod and many others ...
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Paco-general mailing list
> Pac...@li...
> https://lists.sourceforge.net/lists/listinfo/paco-general
>
>


-- 
~David

Re: [Paco-general] Patch for prefixing

[Steven F. <bt...@go...>]

OOps, programmed in branch instead of trunk ...
but now I made it still better :D

On Sat, 2009-03-28 at 22:48 +0100, Steven Falken wrote:
> Hi,
> although there is often the possibility (in the installation procedure
> of a tarballed program) to use make DESTDIR=/foobar to install a program
> somewhere else, it doesn't exist (or even work) always. So I thought
> about to do this via paco. I wrote some code and here it is. 'till now
> there is no support for the paco/gpaco frontend; you have to do it the
> old way LD_PRELOAD .... 
> Whats still needed? mkdir, mknod and many others ...

[Paco-general] Patch for prefixing

[Steven F. <bt...@go...>]

Hi,
although there is often the possibility (in the installation procedure
of a tarballed program) to use make DESTDIR=/foobar to install a program
somewhere else, it doesn't exist (or even work) always. So I thought
about to do this via paco. I wrote some code and here it is. 'till now
there is no support for the paco/gpaco frontend; you have to do it the
old way LD_PRELOAD .... 
Whats still needed? mkdir, mknod and many others ...

Re: [Paco-general] pacoball: don't archive content of catalogs

[Sergei B. <se...@bs...>]

Hi David,

On Sunday 09 September 2007, David Rosal wrote:
> Could you try again with version 2.0.3?

I retested with paco-2.0.3 and it works OK! I.e. paco not logs directories.

But it means also that empty directories (created by install scrips) will not 
be logged by paco and will not be archived/restored by pacoball. It's not 
good.

For example install script of hal-0.5.9.1 creates three empty directories 
in /usr/local/etc/hal/fdi/. If that directories is absent then daemon hald 
will not start:
  $ hald --daemon=no --verbose=yes
  ---skip-----
  17:37:42.592 [E] osspec.c:310: Unable to inotify_add_watch() 		
for '/usr/local/etc/hal/fdi/preprobe': No such file or directory
  *** [DIE] osspec.c:watch_fdi_files():389 : Error watching fdi files
  $


--
Sergei Butakov

Re: [Paco-general] pacoball: don't archive content of catalogs

[Sergei B. <se...@bs...>]

On Saturday 08 September 2007, David Rosal wrote:
> Sergei, which version of paco are you using?
>
1.10.12

--
Sergei Butakov

Re: [Paco-general] pacoball: don't archive content of catalogs

[Sergei B. <se...@bs...>]

Hi David,

On Friday 07 September 2007, David Rosal wrote:
> Hi Sergei.
>
> This is quite strange.
>
> Is /usr/share/autoconf a symbolic link in your system?

No:
	$ ls -ld /usr/share/autoconf
drwxr-xr-x 7 root root 4096 Aug 23 13:19 /usr/share/autoconf


And autoconf-2.60-paco.tar is not the only file with that trouble - I have 
many such one.
They all made by commands like
	$ find /usr/share/doc/some_prog | paco -lp+ some_prog
or
	$ cat some_file_with_list_of_files | paco -lp+ some_prog
where output of 'find' and 'cat' have paths to directories.

Paco_log after commands like
	$ paco -lp some_prog "make install"
don't have paths to directories.
But it denotes that empty directories was not archived and will not be 
restored. It's not OK - some programs don't work correctly without those 
empty directories.


--
Sergei Butakov

Re: [Paco-general] pacoball: symbol links to absent files/catalogs must be archived too

[Sergei B. <se...@bs...>]

Hi,

On Friday 07 September 2007, David Rosal wrote:
> Hi Dan.
>
> 2007/9/7, Dan Nicholson <dbn...@gm...>:
> > I don't really know perl, but it looks like both patches have a
> > problem. The script was changed from
> >
> > ( -e $_ )
> >
> > to
> >
> > ( -l $_ || -e _ )
> >
> > Shouldn't it still be -e $_?
>
> Yes. The patch has a typo. But it has been fixed in SVN.


The patch is right. '_' in '-e _'  signifies "use cached result of previous 
command '-l $_' for test '-e'".

( -l $_ || -e $_ ) - two calls to file system to the same file
( -l $_ || -e _ )  - one call to file system - two times quicker than previous 
clause!

--
Sergei Butakov

Re: [Paco-general] pacoball: symbol links to absent files/catalogs must be archived too

[David R. <dav...@gm...>]

Hi Dan.

2007/9/7, Dan Nicholson <dbn...@gm...>:
>
> I don't really know perl, but it looks like both patches have a
> problem. The script was changed from
>
> ( -e $_ )
>
> to
>
> ( -l $_ || -e _ )
>
> Shouldn't it still be -e $_?
>

Yes. The patch has a typo. But it has been fixed in SVN.


   *david

Re: [Paco-general] pacoball: symbol links to absent files/catalogs must be archived too

[Dan N. <dbn...@gm...>]

On 9/7/07, David Rosal <dav...@gm...> wrote:
> Hi Sergei.
>
> 2007/9/7, Sergei Butakov <se...@bs...>:
> > Hi,
> >
> > P.S. I tested it only with paco-1.10.12.
> >
>
> Thanks for the patch. I applied it to the SVN branch.

I don't really know perl, but it looks like both patches have a
problem. The script was changed from

( -e $_ )

to

( -l $_ || -e _ )

Shouldn't it still be -e $_?

--
Dan

Re: [Paco-general] pacoball: don't archive content of catalogs

[Sergei B. <se...@bs...>]

Hi Rosal,

On Friday 07 September 2007, David Rosal wrote:
> Hi Sergei.
>
> 2007/9/7, Sergei Butakov <se...@bs...>:
> > Hi,
> >
> > When command 'tar' have on input path to catalog, then it archive all
> > content
> > of that catalog. It's wrong.
>
> With "catalog" you mean "directory"? In that case there's no problem since
> paco does not log directories.
>

It's strange, but I have for example: 

$ tar -tf autoconf-2.60-paco.tar | sort
usr/bin/autoconf
usr/bin/autoheader
usr/bin/autom4te
usr/bin/autoreconf
usr/bin/autoscan
usr/bin/autoupdate
usr/bin/ifnames
usr/share/autoconf/
usr/share/autoconf/autoconf/
usr/share/autoconf/autoconf/
usr/share/autoconf/autoconf/autoconf.m4
usr/share/autoconf/autoconf/autoconf.m4
usr/share/autoconf/autoconf/autoconf.m4
usr/share/autoconf/autoconf/autoconf.m4f
usr/share/autoconf/autoconf/autoconf.m4f
usr/share/autoconf/autoconf/autoconf.m4f
usr/share/autoconf/autoconf/autoheader.m4
usr/share/autoconf/autoconf/autoheader.m4
usr/share/autoconf/autoconf/autoheader.m4
usr/share/autoconf/autoconf/autoscan.m4
usr/share/autoconf/autoconf/autoscan.m4
usr/share/autoconf/autoconf/autoscan.m4
usr/share/autoconf/autoconf/autotest.m4
usr/share/autoconf/autoconf/autotest.m4
usr/share/autoconf/autoconf/autotest.m4
---and so on-----


--
Sergei Butakov 

Re: [Paco-general] pacoball: symbol links to absent files/catalogs must be archived too

[David R. <dav...@gm...>]

Hi Sergei.

2007/9/7, Sergei Butakov <se...@bs...>:
>
> Hi,
>
> P.S. I tested it only with paco-1.10.12.
>

Thanks for the patch. I applied it to the SVN branch.


    *david

Re: [Paco-general] pacoball: don't archive content of catalogs

[David R. <dav...@gm...>]

Hi Sergei.

2007/9/7, Sergei Butakov <se...@bs...>:
>
> Hi,
>
> When command 'tar' have on input path to catalog, then it archive all
> content
> of that catalog. It's wrong.


With "catalog" you mean "directory"? In that case there's no problem since
paco does not log directories.

For example, if some program was installed to /usr/share/some_prog and have
> next pacolog:
> /usr/share
> /usr/share/some_prog
> then pacoball will do tar-archive for that program which have _all_
> content
> of /usr/share catalog. Also /usr/share/some_prog will be archived twice
> (first
> as member of catalog /usr/share and then as /usr/share/some_prog itself).
>
> So, it's better to use command 'cpio' which archive catalog itself without
> its
> content.
>
> P.S. I tested it with paco-1.10.12 only but I think it must work with
> paco-2.0.3 too.
>
> --
> Sergei Butakov
>

[Paco-general] pacoball: symbol links to absent files/catalogs must be archived too

[Sergei B. <se...@bs...>]

Hi,

P.S. I tested it only with paco-1.10.12.

--
Sergei Butakov

[Paco-general] pacoball: don't archive content of catalogs

[Sergei B. <se...@bs...>]

Hi,

When command 'tar' have on input path to catalog, then it archive all content 
of that catalog. It's wrong.

For example, if some program was installed to /usr/share/some_prog and have 
next pacolog:
/usr/share
/usr/share/some_prog
then pacoball will do tar-archive for that program which have _all_ content 
of /usr/share catalog. Also /usr/share/some_prog will be archived twice (first 
as member of catalog /usr/share and then as /usr/share/some_prog itself).

So, it's better to use command 'cpio' which archive catalog itself without its 
content.

P.S. I tested it with paco-1.10.12 only but I think it must work with 
paco-2.0.3 too.

--
Sergei Butakov

Re: [Paco-general] Format of the log file ?

[David R. <dav...@gm...>]

Hello Kevin.

2007/8/23, Kevin Williams <kev...@gm...>:
>
> Hi David,
>
> Unfortunately, that didn't work for me. I set BLOCK_SIZE=1 in pacorc and
> updated database "paco -au". That did update the log files but, the sizes
> I
> see in the log files are still apparent sizes and not the real ones. It
> doesn't seem to be working for some reason. Even with the installtion of
> new
> packages, only apparent sizes are being logged ! Any ideas ?
>

This is a bug. I have fixed it in SVN.

Thanks!

    *david

Re: [Paco-general] Format of the log file ?

[Kevin W. <kev...@gm...>]

Hi David,

Sorry for the late reply and thanks again for your time and help.

> Mmm... this is an obscure and known bug. It occurs when you try to log a
> package from within the sources directory of a different package. In your
> case, you probably logged sip from the sources directory of pcre, and paco
> read the pcre's config.log thinking it was the sip's one.
>

Yes, I seemed to have missed that one ! :-) 

I didn't realize that I were in pcre sources directory ! Apologize for my 
ignorance ! :-)  Yes, you were right. I just tried logging from from my home 
directory and paco didn't include the config line at all. So, that's OK. 
Thanks for pointing out.

> Sizes are apparent by default. This is because I appreciate that the size
> given by "paco -ast" is as close as possible to that of  "df -h". If you
> want sizes to be the "real" ones, just set  BLOCK_SIZE=1 in pacorc, and
> update the database with "paco -au".

Unfortunately, that didn't work for me. I set BLOCK_SIZE=1 in pacorc and 
updated database "paco -au". That did update the log files but, the sizes I 
see in the log files are still apparent sizes and not the real ones. It 
doesn't seem to be working for some reason. Even with the installtion of new 
packages, only apparent sizes are being logged ! Any ideas ?

> As you know this is not possible by now, and I don't plan to add that
> feature in the future.
> If you don't want the documentation or the locale data to be logged, just
> use the option --exclude when logging a package, passing it the appropiate
> arguments, or use the variable EXCLUDE in pacorc if you want a more
> permanent setting.
>
> For instance:
>
> $ paco -lp foo --exclude="/usr/share/doc:/usr/share/locale" make install
>

Well, it doesn't hurt me in anyway as, I can manually edit/update the log 
files.

Thanks for the help with "--exclude" switch. I didn't know it could work with 
files too. I presumed it worked only with directories ! That is convenient 
way of excluding files which are not meant to be logged ! :-)

Thanks for your help again and best regards,

Kevin

On August 16, 2007 13:27:41 David Rosal wrote:
> Hello Kevin.
>
> 2007/8/13, Kevin Williams <kev...@gm...>:
> > Hi David,
> >
> > Thanks a million for you detailed response. I really appreciate it.
> >
> > > > This works except the fact that, the configure options used for the
> > > > compilation are actually copied from that of the paco itself.
> > >
> > > I don't understand this.
> >
> > What I meant was that, when I create a paco log file from a file
> > containing
> > the list of files for a package already installed using the command
> > below, paco seems to copy the config line of the last package installed.
> >
> > cat <pkg-list-file> | paco -lp <pkg-name>
> >
> > For eg. when I installed sip-4.7 I created a file contanting the list of
> > files
> > installed by sip's 'make install'. Later, I ran paco as above to generate
> > a
> > paco log file for sip-4.7. The sip-4.7 log file contains the following
> > configure line:
> >
> > #c:--docdir=/usr/share/doc/pcre-7.2 --enable-utf8 --prefix=/usr
> > CFLAGS=-mtune=pentium4m -march=pentium4m -msse2 -pipe -fomit-fr
> >
> > As you can see, it apparently copied that line from the pcre-7.2 log file
> > which was the most recent log file in /var/log/paco.
>
> Mmm... this is an obscure and known bug. It occurs when you try to log a
> package from within the sources directory of a different package. In your
> case, you probably logged sip from the sources directory of pcre, and paco
> read the pcre's config.log thinking it was the sip's one.
>
> Well, it is really not an issue, as I found out what the 2nd and 3rd lines
>
> > of
> > the log file mean. Before this, I didn't know what the 2nd and 3rd lines
> > in
> > the log file were, I thought of them to be some sort of checksum for the
> > logfile itself. So, I was a bit reluctant to modify the log file by hand.
> >
> > I'm just laying out my understanding of 2nd and 3rd lines of the logfile,
> > please correct me if I'm wrong.
> >
> > The 2nd line consists of 4 fields delimited by '|'
> >
> > The first is the total size of package
> > The second field is 'size missing'
> > The third field is 'No. of files the package contains'
> > The fourt field is 'Files Missing'
> >
> > The 3rd line stores the time stamp in 'seconds in epoch' format.
>
> You're right.
>
> All these things became clear when, I launched gpaco !! :-)
>
> > I couldn't help wonder as to why are the sizes are apparent sizes and
> > hence,
> > not the actual file sizes ?!
>
> Sizes are apparent by default. This is because I appreciate that the size
> given by "paco -ast" is as close as possible to that of  "df -h". If you
> want sizes to be the "real" ones, just set  BLOCK_SIZE=1 in pacorc, and
> update the database with "paco -au".
>
> > Also, I thought there should be a way to just remove aline from the
> > logfile.
> > There're cases when, I don't want documentation installed in other
> > languages
> > besides english and hence, I normally delete those files. I can do so
> > with paco or gpaco but, paco log files still contain the references to
> > the removed
> > files and thus add to the overhead. There should be a way to just delete
> > these files and not have any references/records of them at all. Ofcourse,
> > this is just my opinion.
>
> As you know this is not possible by now, and I don't plan to add that
> feature in the future.
> If you don't want the documentation or the locale data to be logged, just
> use the option --exclude when logging a package, passing it the appropiate
> arguments, or use the variable EXCLUDE in pacorc if you want a more
> permanent setting.
>
> For instance:
>
> $ paco -lp foo --exclude="/usr/share/doc:/usr/share/locale" make install
>
>
> Cheers.
>
>
>     *david