<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Kris Moore wrote:
<blockquote
 cite="mid:alpine.BSF.2.00.0907211634270.32883@hubble.localhost"
 type="cite">
  <pre wrap="">
This is a good idea, that I've also given some thought, but here's the problem that needs
to be overcome first. Our PBIs are each compiled with a different LOCALBASE, which changes
pretty much constantly.

I.E:

/Programs/FireFox3.0.1
/Programs/FireFox3.5.0

This LOCALBASE change effects all the packages / binaries / libraries that are compiled. If we did
use a saved package, then the libraries would be set to /Programs/FireFox3.0.1 as their LOCALBASE,
but the real LOCALBASE should be /Programs/FireFox3.5.0 now. The only way I've found to fix this is
by re-compiling the packages, which is what it does now.

--
Kris Moore
PC-BSD Software

On Tue, 21 Jul 2009, A.Yerenkow wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello all!
I'm again writing some crazy concept about PBIs ;)
Kris, and othersm if you have time, please read this :)

1.
Currently, to build a PBI, all sources must be compiled from scratch.
But we have "distfiles" dir, this is for "not download same thing over
and over"
Why we haven't same way for storing built packages? Like for example
wide-used?
I try to explain how this can be done, in good way.
We need two directories,
"packages"
and
"packages_info"

2.
make -C category/portname -V PORTVERSION
can give us the exact version of any port (I hope).
make -C category/portname -V LIB_DEPENDS
make -C category/portname -V RUN_DEPENDS
make -C category/portname -V BUILD_DEPENDS
can give us the ports, on which we are depends.

Assume we are building port "misc/sys1", version 2.00
It depends on "misc/libone", version 4.5
let's make package of misc/sys1, it could be something like
sys1-2.00.tbz;
let's store it in
"packages"
and let's create file
"packages_info/misc-sys1.info"
contains info about self version, and about each dependency port:
misc/sys1{TAB}2.00
misc/libone{TAB}4.5

3. The logic of usage of this is simple:

clear-files:
    foreach ls packages_info/* as packageinfo
    if version from packageinfo didn't match that in ports tree:
    delete all packages and info, which have dependency on packageinfo,
recursively,
     (so in the end there will be no package exist which depend on lib
which depend on lib2 which depend on this particular port -- I hope,
this is clear: )

create-list-of-ports-to-build-specified-port
    find all dependecies for this port, for this dependencies, and etc,
make an ordered list of this;
    (if port A depend on B, and B depend on C and D, and D depends on
E, list will be E,D,C,B,A)

iterate-by-list-and-create-all
    iterating by creates list
    if we have package - pkg_add it;
    if we haven't package - build package, and store info about all
required packages.


4. What this give us?
This give us a boost in PBI building. While there are less than 100 of
them, maybe that's not so significant, but later... :)
Currently, we have 28 wine's built every time, and that's first level
dependency (it's OTHERPORT, and not RUN_ or LIB_ or BUILD_ dependancy)
And we always can have different packages stored, for different
MAKE_OPTS, for example storing package as
pkg_name_MD5(MAKE_OPTS).tbz

Ideas/Comments MUCH appreciated!



_______________________________________________
Testing mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Testing@lists.pcbsd.org">Testing@lists.pcbsd.org</a>
<a class="moz-txt-link-freetext" href="http://lists.pcbsd.org/mailman/listinfo/testing">http://lists.pcbsd.org/mailman/listinfo/testing</a>

!DSPAM:1,4a6624d915807623594501!



    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
Testing mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Testing@lists.pcbsd.org">Testing@lists.pcbsd.org</a>
<a class="moz-txt-link-freetext" href="http://lists.pcbsd.org/mailman/listinfo/testing">http://lists.pcbsd.org/mailman/listinfo/testing</a>

  </pre>
</blockquote>
Or go with the, from what I can tell, Open Office PBI way and install
in .../Programs/ProgramName and store the version name and other PBI
information in a .info (or w/e) file containing said information. That
is assuming I understand the goal here.<br>
<br>
Orrr start a tree .../Programs/ProgramName/ProgramVerA ...<br>
<br>
brodey<br>
</body>
</html>