pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ANN: Availability of pkg(8)-capable pkgsrc



from John Marino:

> On 11/13/2016 02:06, Thomas Mueller wrote:
> > I have some NetBSD installations, now idle pending update, following
> > a crash that corrupted the GPT partition table, though I subsequently
> > seem to have recovered all data.

> > Can this pkg(8)-capable pkgsrc be used on an installed system with
> > many packages, or do I need to clean everything first?
        
> I haven't tested it and I wouldn't recommend it, but I think it would be
> possible to convert without cleaning first.  Your system would be rather nasty
> because everything that is previously installed will be without registration
> until they are rebuilt and reinstalled.
        
> I would clear everything in /usr/pkg/* first or at least remove /usr/pkg from
> the PATH and choose a new localbase.

FreeBSD had/has pkg2ng to convert an installation from the old pkg_* tools to the new pkgng.

I guess this has not (yet) been ported to NetBSD or pkgsrc and can guess it would not be trivial.
        
> > Can synth be used in place of pkg_rolling-replace to update installed
> > packages?
        
> yes.
> caveat 1) Synth hasn't been ported to pkgsrc yet.  There are a few challenges,
> the biggest being multi-version support.  If/when synth comes, it may be
> limited to one version of each MV type initially.
        
> caveat 2) It's not synth handling the inline replacement.  Pkg(8) is doing it.
> Synth provides the repository of package on which pkg(8) operates.  Synth will
> build/rebuild what is required, update the repository, then pkg(8) will handle
> the system updates seamlessly.

> tldr; pkg_rolling-replace is a relic of the current "pkg" format which is
> unnecessary (and probably unsupported) with the "pkgng" format.

So now with pkg(8)-capable pkgsrc in its infancy, there would be a transitional phase where pkg_rolling-replace wouldn't work, and Synth wouldn't be ready.

So how would packages in NetBSD be updated with portmaster and portupgrade not available?

> > Can I download through "git clone" rather than the master.zip, and
> > would I update by "git pull"?  I could do that from either FreeBSD or
> > NetBSD.

> Of course.  I only use master.zip as an example because a clean system
> wouldn't have git already installed.  Using git would be preferred.

I could use git from an already existing installation of FreeBSD or NetBSD.

With old-style disklabels, FreeBSD and NetBSD might not be able to read each other's installations, but I have given up on old-style disklabels in favor of GPT.

I have to say FreeBSD handles GPT partitions much more elegantly than does NetBSD, even more elegantly than does Linux.

Dynamic device nodes as in modern versions of FreeBSD and Linux are much easier to deal with than the preconfigured device nodes of NetBSD and OpenBSD, and old versions of FreeBSD and Linux.

> > I have substantial experience with pkg on FreeBSD, where I build
> > packages through FreeBSD ports.

> > I just looked in pkgtools and sysutils categories through the github
> > web interface, and synth was not there.

> Correct.  I spent an embarrassing number of days just getting pkg(8) to work
> pkgsrc.  I haven't even started work on Synth (the porting will not be
> trivial).  I was also observing how USERS would receive pkg(8).  If it's a dud
> then there's not to much point in continuing the synth work.

> If you still have those FreeBSD boxes, I recommend that you use Synth there,
> if for no other reason than to become familiar with it.

Porting software between FreeBSD and NetBSD is nontrivial; this applies also to Ethernet and wireless networking drivers.

I notice Rod Smith's gdisk has not been ported to NetBSD, and FreeBSD port is some versions behind.  I also notice some web browsers in FreeBSD ports but not in pkgsrc (xombrero, chromium).

Tom


Home | Main Index | Thread Index | Old Index