"pkg updating" is unreliable

mer said:
Don't depend on metadata which is generated by humans (or AI :) ) but on actual system linking (ldd).
Click to expand...
Another thing to mention is that pkg does NOT record BUILD_DEPENDS as dependencies.
This is fair from the point of view of local admins / users that use pkg to install pkgs. But insufficient from the maintainers' point of view.

And this behavior, unlike legacy bare-metal ports upgrading tools, could cause runtime issues that maintainers "cannot" notice when any of the components provided by any of BUILD_DEPENDS are actually needed in runtime, too.
Yes, within the environment that maintainers have, there are BUILD_DEPENDS installed, unless the maintainer uses only clean-room builders like poudriere to build ports and have no BUILD_DEPENDS installed.
But for old enough guys who exulted over the appearance of portupgrade like me, installing BUILD_DEPENDS regardless using directly or not is quite mature.
 
Forgot to mention.
One of what hidden dependencies harm would be noticed in cases like below.
  1. Port C chanded its ABI (regardless API is kept backward compatible or not).
  2. Port B is fixed (simple PORTREVISION bump is sufficient if API is kept backward compatible) to follow the change, but port A did nothing, as the maintainer of port A believes port C is 100% wrapped by port B at least what port A requires.
  3. Port A starts crashing (or mis-behaving without crash). Or start failing build (link) if the new API of port C is NOT backward compatible.
If build failures happen, exp-run helps, but if not, exp-run cannot help at all, as exp-run means thoroughly build tests, not runtime tests.
 
I don't know how useful this will be, but:

I've used Synth for years. It has always done a lot of scanning to figure out what is related to what, and how so. Plus, ever since FLAVOR became a thing, Synth has always taken even longer -- a loooooooooooong time -- "Scanning entire ports tree" while "Regenerating flavor index". I once asked the author if this was really necessary to do, or if perhaps there were some shortcuts that could be taken. I forget if he didn't give details or else he gave details that I didn't really understand, but in any case, I do remember that he responded, and the answer was "Yes, it is really necessary".

In general I have been very happy with Synth, and I trust it to do the right thing a whole lot more than I've ever trusted any other FreeBSD build mechanism I've used, going back literally decades (disclaimer: I've never used Poudriere... because I've been so satisfied with Synth). I base this on having run into a bunch of build problems over the years, and while I won't say that not a single one of them in the time I've been using Synth was because of Synth, I will say that the following is by far the most common thing in my experience (with the possible exception of problems that were simply due to my own misunderstanding of something):

1. I run into a build problem.
2. I post somewhere about it (like Bugzilla or here on the FreeBSD forums).
3. Someone blames it on Synth, without giving any real evidence.
4. I post about it on the Synth forums.
5. The Synth author convincingly demonstrates that it is not the fault of Synth, and is in fact the fault of <some-other-thing>.
6. I go back-and-forth between the two forums, essentially as a messenger.
7. Eventually everybody's on board with the idea that it is the fault of <some-other-thing>, not of Synth.
8. A fix is issued for <some-other-thing>.

So I guess what I'm trying to say is, maybe looking at the Synth source code can be used to get some good ideas for how this sort of thing is correctly done.
 
T-Aoki said:
It would be because the very first developer of portupgrade chose ruby over sh to handle complicated dependency graph. And, if I recall correctly, ruby-haters started developing portmaster in sh.
Click to expand...
My implementation is in JavaScript (and is in heavy development state) and only works with ports, not packages, it can be however easily ported to C++. Apart this, sh can be run in a fresh installed system, it does not require other ports to execute it nor to be compiled, but the language does not have objects to easily manage required information (or better, I have not knowledge about the ins and outs of the language).
 
freethread said:
My implementation is in JavaScript (and is in heavy development state) and only works with ports, not packages, it can be however easily ported to C++. Apart this, sh can be run in a fresh installed system, it does not require other ports to execute it nor to be compiled, but the language does not have objects to easily manage required information (or better, I have not knowledge about the ins and outs of the language).
Click to expand...
Even if any scripts from ports are written in sh, it is needed to be installed via ports or pre-built packages (at the era portupgrade first appeared, pkg(8) was not yet started to be developed, thus, called "packages"). So there are no mutual and large differences from the point of local admins.

The mutual difference would be portmaster, written in sh, can be in base anytime in the future once ports framework is frozen (considered perfect in specifications and no longer require new features, thus, bugfixes alone are done) and release engineering team allows to do.

But at least currently, ports framework itself is under active developments, thus, "moving goal", and disallow even pkg(8) to be in base except bootstrap part.
 
T-Aoki said:
The mutual difference would be portmaster, written in sh, can be in base anytime in the future once ports framework is frozen (considered perfect in specifications and no longer require new features, thus, bugfixes alone are done) and release engineering team allows to do.
Click to expand...

I can't see that ever happening.
 
You must log in or register to reply here.
Back
Top