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

A.Yerenkow yerenkow at uct.ua
Tue Jul 21 13:45:47 PDT 2009


On 21.07.2009 23:37, 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.
>
>    
The package can be modified before installation;
unpack; change in file +CONTENTS
line
@cwd /Programs/FireFox3.0.1
  to
@cwd /Programs/FireFox3.5.0
pack;
pkg_add then;

Do we have any other stoppers?

> --
> 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
>    


-- 
Best Regards
Alexander Yerenkow,
Generalissimo of UCT



More information about the Testing mailing list