[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.
> 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 :)
>> 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
>> I try to explain how this can be done, in good way.
>> We need two directories,
>> 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
>> let's store it in
>> and let's create file
>> contains info about self version, and about each dependency port:
>> 3. The logic of usage of this is simple:
>> 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,
>> (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: )
>> 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)
>> 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
>> Ideas/Comments MUCH appreciated!
>> Testing mailing list
>> Testing at lists.pcbsd.org
> Testing mailing list
> Testing at lists.pcbsd.org
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...
More information about the Testing