[PC-BSD Testing] Small thought about PBIs... Request for comments :)

doverosx at gmail.com doverosx at gmail.com
Tue Jul 21 13:53:01 PDT 2009

Kris Moore wrote:
> 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:
>> 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
>> Testing at lists.pcbsd.org
>> http://lists.pcbsd.org/mailman/listinfo/testing
>> !DSPAM:1,4a6624d915807623594501!
> _______________________________________________
> Testing mailing list
> Testing at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/testing
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.

Orrr start a tree .../Programs/ProgramName/ProgramVerA ...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/testing/attachments/20090721/4b39bee8/attachment.html>

More information about the Testing mailing list