Get ports tree of the current pkgng repository
s-tlk at s-tlk.org
Thu Aug 16 22:07:19 UTC 2012
On Thu, 16 Aug 2012, Matthew Seaman wrote:
> On 16/08/2012 20:56, Michael Schnell wrote:
>> I don't know if this came up already, but not as far as I know. So, I
>> was thinking it would be nice to add a mechanism to pkgng, which enables
>> the user to get the ports tree corresponding to the current repository.
>> At least I've the problem that I really like the idea of the pkgng
>> system, but I need a few custom build packages. For instance rawtherapee
>> is not working for me with OpenMP, so I have to disable it to get it
>> working, or I made some patches for openbox, which of course then needs
>> to be compiled. In order to get not in conflict with a more recent
>> ports tree the exact version of the repository build would be nice.
>> At the moment I can think of two ways to implement it. The easiest way
>> would be to add the ports tree as a packages into the repository. A more
>> complicated thing is to add a mechanism to portsnap synchronised with
>> the pkgng system to direct fetch it, or at least a revision number of
>> the current repo, so you can check it out of the subversion.
>> How do you guys feel about this?
> Could you open an issue on github please? [*]
Okay done. Unfortunately I don't have a test system yet, then I would
have tried to test some of the ideas. At the moment I'm just evaluating
> Adding a package with a complete ports tree is an ... interesting ...
> idea. Maybe doable --- but it would be a huge package. Adding some
> metadata to the repo catalogue to show eg. the SVN revision number of
> the ports tree used to generate the packages would be a pretty
> reasonable approach.
I don't think it will be so large, when you look at the size of the
compressed tar balls coming with portsnap. ;-)
Something around 65 MiB if I remember correctly?
> However, one of the development aims for pkgng is to make it much easier
> for people to maintain their own packages of the particular software
> that is important to them, but be able to use a regular public
> repository for pretty much anything else. That implies being able to
> handle a mix of packages compiled from different ports trees much better
> than is the case at the moment. If we get that right, keeping ports
> trees in precise synch as you describe shouldn't be any great issue.
That was my idea. Otherwise I have to guess the revision, or check out
the ports tree quickly after an upgrade of the packages and still I had
some mismatch there.
More information about the freebsd-stable