On Thu, 16 Aug 2012, Matthew Seaman wrote:

On 16/08/2012 20:56, Michael Schnell wrote:
Hi,
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? [*]

https://github.com/pkgng/pkgng/issues?state=open

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

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.


Greetings
Michael

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to