search

outpaddling / desktop-installer

Quickly configure a FreeBSD or NetBSD desktop system
BSD 2-Clause "Simplified" License
57 stars 9 forks source link

Run the script without initializing a ports tree? #13

Closed yzgyyang closed 3 years ago

yzgyyang commented 3 years ago

One of the first steps is to confirm if one wants to replace /usr/ports with a shallow clone - it sounded optional at that step, but if chosen no on a fresh system (/usr/ports empty), then all the following package installation will fail. So my questions are:

Thanks!

linimon commented 3 years ago

On Wed, Jun 02, 2021 at 02:53:19PM -0700, Guangyuan Yang wrote:

  • Why do we need the ports tree as a hard requirement even if we are using pkg for all the following installations?

There is code in there to test if ARCH is supported, but:

I am poking at desktop-installer aarch64 to try to generalize things. Right now my advice is "do not try this on aarch64" :-)

mcl

linimon commented 3 years ago

Well, it's actually worse than the above :-)

The ports tree is also used to display pkg-descr, if it exists. This is the wrong technology and should be replaced with pkg rquery.

Reworking this is going to be non-trivial, but it is a necessity for !x86 (and helpful for robustness in any case).

outpaddling commented 3 years ago

One of the first steps is to confirm if one wants to replace /usr/ports with a shallow clone - it sounded optional at that step, but if chosen no on a fresh system (/usr/ports empty), then all the following package installation will fail. So my questions are:

* Why do we need the ports tree as a hard requirement even if we are using `pkg` for all the following installations?

* If we have a reason for the above Q, can we incorporate the reason to the ports tree prompt?

Thanks!

Using binary packages for all installs is impossible for many users, since there are ports that don't allow packaging, mostly due to license restrictions. For full functionality we have to fall back on source builds occasionally. Until recently this included things like faac, lame, and exfat. All of these are currently available as binary packages, but I would not assume they always will be. Also, a recent KBI compatibility issue made it necessary to install drm-kmod from source on FreeBSD 12.2 until 12.1 reached EOL and package builds switched to 12.2.

So maintaining the ability to install from source is sometimes critical to basic functionality and not having a ports tree at all is not something I would attempt to support.

This also means that installed packages and the ports tree must be kept in sync to the extent possible, which is the job of auto-update-system.

This issue points to a bug in the git transition code. The prompt you hit was meant for transitioning from portsnap or svn to git and should not come up if the ports tree is empty. I'll investigate this - thanks for the heads-up.

outpaddling commented 3 years ago

The ports tree is also used to display pkg-descr, if it exists. This is the wrong technology and should be replaced with pkg rquery.

Not quite. There are cases where we want to install things that are not available as a binary package. Currently they don't include anything for which pkg-descr is displayed, but since the ports tree will always be a requirement for desktop-installer, I would not risk creating problems by changing this strategy.

yzgyyang commented 3 years ago

I think the quickest way to minimize impact to the users right now is to print additional messages during the ports step stating that "we can get a ports tree for you or you verify if the ports tree is already there, but we need one no matter what, otherwise the script cannot continue and WILL fail." Otherwise, I would expect it to be optional, choose no and ended up getting errors.

There are cases where we want to install things that are not available as a binary package. Currently they don't include anything for which pkg-descr is displayed, but since the ports tree will always be a requirement for desktop-installer, I would not risk creating problems by changing this strategy.

When I chose mate on an amd64 machine, all installation seems to be done by pkg not ports - not saying that we should not use ports at all, but is it possible to only fail an install when we actually are using ports to install stuff? ;)

outpaddling commented 3 years ago

I just committed a simple change to auto-check-ports-branch in WIP. It checks for $PORTSDIR/Makefile rather than just $PORTSDIR. If missing, a ports tree is checked out unconditionally. The only way to trip up this check is by having an incomplete ports tree installed.

I'm not totally clear on your question about only failing when using ports, but desktop-installer sets AUTO_BUILD_FROM_SOURCE=fall-back, so if a pkg install fails, auto-install-packages attempts to install from source before giving up.

outpaddling commented 3 years ago

Committed auto-admin fix.

outpaddling commented 3 years ago

Closing this since I believe the original issue is resolved. I also just committed some changes to WIP that allow desktop-installer to complete on aarch64 (tested the script on Rock64, though no console is available, so X11 function is not verified). aarch64 still has many other issues such as lack of XFCE, Gnome, and KDE packages. But desktop-installer should work now with an available DE/WM (e.g. Lumina, FluxBox, IceWM) on a platform with working graphics (e.g. RockPro64).