[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: revbumps [was Re: suggestion: Host fly-off between pkgin and nih and subsequent official integration]
On 4/16/2013 20:19, Greg Troxel wrote:
John Marino<netbsd%marino.st@localhost> writes:
Honestly I think the "make replace" issue is the main one. If that
were fixed, I could live with dependence rebuilds. It's just time
(unless I don't have much, then it's still annoying.)
What specific 'make replace' issue do you mean? The biggest problem as
I see it is that when files move from one package to another there is no
way to replace packages individually.
As for installing one package, pkgsrc expects a consistent checkout of
src, and a set of installed packages that are consistent with that. So
the rule is first do pkg_rr (or similar) and then you can build things.
If you don't like that you should be using the stable branch.
So you see that the scenario I've been talking about violates the
premise. For example, In January I build a bunch of packages from the
master branch. Six months later, in July, I pull the latest source on
the master branch and try to "make install" some package. Now pkgsrc
tries to rebuild a bunch of packages that are already installed and each
one fails at "make install" because the package is already installed.
It basically has no way of detecting the package is already installed
and replacing it. It just fails, and about 20 more upstream will fail
too. I either have to "make replace" each failure or use the "rolling
Now, you may say I'm misusing pkgsrc, and I never should have pulled
from the master branch again. Or that I should have rebuilt everything
in a chroot root and used a package manager to replace all the outdated
packages. I don't think my use case is crazy though.
Now, it would be a feature to do something where one can essentially do
pkg_rr projected onto the dependencies of a single package, plus any
rebuilds that are required from that. But I'm not sure that's really a
good idea because it accomodates more inconsistency than pkgsrc usually has.
To iterate, I think of a lot of the frustration that people that people
from source (constantly updated trunk branch) experience with pkgsrc
could be mitigated if it just didn't break on "make install". I guess
functionally this is what "rolling replace" is doing but that tool never
seems to work without incident. I am suggested if "make install" were a
bit smarter, the RR tool could be eliminated completely.
Main Index |
Thread Index |