[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg_add and remote packages
>>>>>> And I don't see chicken-and-eggs problem. ftp client, pax are
>>>>>> already in bootstrap.
>>>>> Ever tried to update them? :-)
>>>> source based upgrade?
>>> Binary. In case of bmake source.
>> I meant that source-based upgrade may be used for this.
>> I will not repeat you how to solve chicken-and-egg problem.
> I'm not sure this is in the spirit of the system.
As far as I understand in NetBSD everybody has its own way.
"there are many ways to do it" (C) :-)
> Why produce
> binaries at all if we have to build from source "sometimes". Also,
> I like to run a production systems without compilers and other
> development tools installed on them.
I'm not sure about commercial UNIX-es but all open source OSes
have both pax/tar/gzip and ftp/http downloaders in their base system
and/or in their own packages.
So, you need source-based upgrades ONLY if you are limited to pkgsrc.
Bootstrapping (made once!) pkgsrc to /usr/pkg_extra is not a problem
IMHO and sometimes it is even helpful. For example, You may want to
install sudo to this directory for running DESTDIR bulk builds (under
NetBSD sudo is not a part of the base system), or to installing pax or
ftp/http downloaders. Some time ago I installed pbulk there.
Now - distbb. Both are for distributed bulk build.
So, this is universal method that works ALWAYS.
ABOUT FTP (VS. LIBRARY). BINARY PACKAGE IS DOWNLOADED FIRST
AND THEN IT IS INSTALLED. I DON'T SEE ANY CHICKEN-AND-EGG PROBLEM AT ALL.
For other packages chicken-and-egg problem is solved differently.
Just a few examples (there are others of course):
- binary ftp:// upgrade (I didn't try this, but I think it should work)
- make replace
- make USE_DESTDIR=full package; pkg_add -u /path/pkg_install-X.Y.Z.tgz
- /usr/pkg_extra described above
- make replace
> Don't get me wrong I build lots of pkgsrc things from source but not
> because I want to.
Me too. I also prefer binary packages.
IMHO advantages of using the external program for fetching are much
more significant than... than what? There is no chicken-and-egg
problem. And I don't understand why this _easy_ work is for loooong
future and is low priority. As I said above, in NetBSD everybody
has its own way and point of view :)
Best regards, Aleksey Cheusov.
Main Index |
Thread Index |