pkg option 'build'

F

friedg

I think it would be useful if pkg had an option for building from source in order to automate the ports tree rather than manually navigating the tree or using one of the script programs that attempts to automate it. For example: pkg build nano. I think there is a program called apt-build from Debian that works similarly to this, which I found useful.
 
No, PKGNG is designed with the assumption that is knows absolutely nothing about how the software is built. It is just a packaging infrastructure and it should stay that way. There are already enough tools for port building and what you propose would add nothing since it would just be yet another front end to ports(7) that is the only working method for building packages and it is going to stay that way. The proposed pkg build command would have the exact same problems as the standard make install method now has, to name a few: lack of dependency tracing and unclean build environments that can trip many builds because of leftover files from previous installations. Not to mention that it would introduce a circular dependency between the packaging tools and the port building tools and that's never a good idea.

If you want to see how well the ports building can be automated with the existing tools take a look at ports-mgmt/poudriere. I have a HOWTO written about it: Thread 38859.

If the standard ports(7) infrastructure was able to do what poudriere is now able to do which is using a jail(8) or a chroot(8) for a clean build environment and figuring out all the tricky details of dependencies there would be no need for any external build tools. I'm however sceptical if that is going to happen any time soon.
 
Re: PKGNG Option build

IMHO portmaster --packages-build --delete-build-only <category/port> may be a fine answer to your needs, somewhere between manual building and your own pkg infrastructure. You can even make an alias in your shell like pkg-build :)
 
Re: PKGNG Option build

ondra_knezour said:
IMHO portmaster --packages-build --delete-build-only <category/port> may be fine answer to your needs, somewhere between manual building and own pkg infrastructure. You can even make alias in your shell like pkg-build :)
Click to expand...

Except that --packages-build won't use the available packages for build dependencies when PKGNG is used. This is a known limitation that may not be fixed in ports-mgmt/portmaster anytime soon because fixing it would require replicating lots of features from ports-mgmt/poudriere to portmaster. With the old style packages the --packages-build option just installed the first available package without any ability to check if the package actually provided the necessary dependency with the right options. Now with PKGNG packages the maintainers of ports-mgmt/portmaster don't want to allow that because it's clearly wrong.
 
Honestly, If I wanted any of these features badly enough I would just do it myself and tell the freebsd FreeBSD people and they can do what they like with it. I just proposed this to see if anyone else had thought of it.

I wasn't suggesting an overhaul of ports management, I was just suggesting an option that would utilize the current system of automating the ports tree.
 
friedg said:
Honestly, If I wanted any of these features bad enough I would just do it myself and tell the freebsd people and they can do what they like with it. I just proposed this to see if anyone else had thought of it.

I wasn't suggesting an overhaul of ports management, I was just suggesting an option that would utilize the current system of automating the ports tree.
Click to expand...

That's exactly what you can do, implement the feature yourself and present it to the PKG developers for inclusion. They may have the same attitude as I do about it or they may not, I'm just making a guess that they will probably agree with me.
 
One of my misgivings about the new pkg system is that in the past persons tinkering with the text-based files would craft portupgrade; portmanager; portmaster on their own initiative. Adding SQL expertise into the mix may muddy their ideas before coding them (inexperienced with it) as well as not encouraging it in the first place (never having read a SQL-to-text equivalent), and add a layer of debugging complexity, etc. I see that particular aspect as reversible if pkg were to add the feature of /var/db/pkg written out on demand or after a change to the database state, or some equivalent. It does not appear from here to be very difficult to recode, or make into a port, or I am mistaken.
 
@@kpa: Hmm, didn't know that. Is there any article/discussion about limitations in portmaster-pkgng interactions you know about?
 
Last edited by a moderator:
You do realise that you're not supposed to use the knowledge that the internals of PKGNG use an SQLite database in any way? It may very well happen that the SQLite database gets replaced by something that doesn't even talk SQL and has no compatibility with SQL. All this can happen without breaking the compatibility of the pkg(8) utilities, all the user would see is that the local package databases are suddenly updated to a new format that still has the same information as the old ones.

So, please everyone. You're not required to learn SQL to use PKGNG packages, not even if you build your own utilities around them. The pkg query is the correct API for that purpose, not the SQL language API to the raw database.
 
ondra_knezour said:
@@kpa: Hmm, didn't know that. Is there any article/discussion about limitations in portmaster-pkgng interactions you know about?
Click to expand...

I don't recall anything specific right now, I have just deduced the reasoning for not supporting --packages-build from what what I know of ports-mgmt/portmaster and how it works. The commit logs at https://github.com/freebsd/portmaster may shed some more light on the issue.
 
Last edited by a moderator:
kpa said:
You do realise that you're not supposed to use the knowledge that the internals of PKGNG use an SQLITE database in any way? It may very well happen that the SQLITE database gets replaced by something that doesn't even talk SQL and has no compatibility with SQL. All this can happen without breaking the compatibility of the pkg(8) utilities, all the user would see that the local package databases are suddenly updated to a new format that still have the same information as the old ones.

So, please everyone. You're not required to learn SQL to use PKGNG packages, not even if you build your own utilities around them. The pkg query is the correct API for that purpose, not the SQL language API to the raw database.
Click to expand...

... the correct API... >> the new API

... installed ports... >> /var/db/pkg >>> ... legacy packages and SECONDARY pkg database (pkgdb.db)
then
... installed ports... >> primary API database >> ... pkg packages and (secondary pkg database, pkgdb.db)...

My point was that coding Unix tools into a ports management port is easier without the new API into installed ports required additional methodologies, as well as a deep understanding of them, and I'd surmise it potentially limits development in that regard. (Unless pkg, or even portupgrade, someday acquires a switch to write it out into/out of that legacy (text) format or an equivalent automagically... it seems more convoluted otherwise.)
 
You must log in or register to reply here.
Back
Top