tech-pkg archive

[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):
+ pkgtools/pkg_install:
 - 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
+ pax
 - /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.


Home | Main Index | Thread Index | Old Index