Challenge:
----------
Libzypp supports parallel download and install. Yast installation progress does
not fit it at all [1]. Issues are secondary progress bar that does not work
with parallel installation. Also there are overwhelming amount of
information on screen that is quite distracting. That information is often
wrong like time estimation. And also table for media is a bit useless nowadays
as everything is on one iso/medium, so there is no need to see when cd switch
will be needed. The details tab are the most visible as it is default one.
Proposal:
---------
Remove completely that details tab and keep just release notes one[2]. It
contains release notes that contain useful information and also has just one
progress bar. For that bar remove keep always just remaining size and count of packages,
so user has idea how it does, but do not print what exactly is installing
or any time estimation. If there are more release notes allow to switch between them.
Also keep possibility to have slide show which we had in past for installation
if someone create some ( when checked other OSes, the Ubuntu slide show during
installation looks probably the best from user POV ).
The same changes will apply to ncurses front end[3], we just need to check why formatting
of release notes are so badly formatted.
And same for opensuse[4] of course.
Josef
[1] https://pasteboard.co/cNBjER6SnLLT.png
[2] https://pasteboard.co/WnI7wS7VVVqq.png
[3] https://pasteboard.co/vzQvY1PaVDaD.png
[4] https://pasteboard.co/FzEqcIN7Xnas.png
Hi all,
I'd like to shortly mention the GitHub Releases here, just in case you do not know
this GitHub feature...
GitHub can not only host the sources for your project, but it can be also used for
distributing the built binaries. For YaST that is not much useful as we use OBS for
that, but many upstream projects use this.
I tried to use this feature for publishing a testing DUD with a fix. Of course, you
can always attach the DUD to bugzilla. But that's not easy to use, you have to
download and host the file on some server [1]. That's annoying.
Example:
--------
I built a testing DUD which can be used directly from GitHub with this boot option:
dud=https://github.com/yast/yast-update/releases/download/bsc_1200127/dud.c…
You do not need to download anything, it just works!
The only minor drawback is that the URL is pretty long and you need to carefully
write that on the boot command line.
You might use an URL shortener service, it tried to minify the URL to
dud=https://bit.ly/3OoevuJ
and it works fine. But you should be careful when using shortened URLs,
you do not know where they actually point to. And even if it looks OK
the author can later edit it and change the target to point to some malicious
file...
Note:
In this particular case I did it mainly for testing purpose, this proposed fix is for
just one customer so it does not make much sense to publish it at GitHub. They will
most likely use the DUD from bugzilla.
But if you have a bug fix which will be used by more users then this GitHub
feature can be very useful.
How to use it?
--------------
1. Go to the main GitHub page of the project, click the "Releases" section header
in the right side bar
2. Clink the "Create a new release" button
3. Select the Git branch name and tag to which this release will be bound to.
A tag is required, if the respective tag does not exit just write some,
GitHub will automatically create it from the selected branch
4. At the bottom there is an area for attaching the binaries, just click it and
select the built files to upload
5. If this is just a testing build (code not merged yet), select the "pre-release"
option so the users know this is not the final version and might be changed
later
6. Press "Publish release"... and that's it!
Enjoy! :-)
GitHub Packages Note
--------------------
There is a similar feature called GitHub Packages. But that supports only releasing
"packages" in some special registry services, like container registry, npm registry,
rubygem registry, etc...
That cannot host arbitrary packages or files. See [2] for more details.
Ladislav
[1] For testing purposes you can always use something trivial like
ruby -run -ehttpd . -p8000
and use the http://<your_IP>:8000/ or http://localhost:8000/ URL
[2]
https://docs.github.com/en/packages/learn-github-packages/introduction-to-g…
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
Hi all,
as already mentioned, we are experimenting with the containerized YaST.
Not all modules work out of box in that environment, some need small adjustments.
To make it easier I created a short document which might help with porting:
https://github.com/yast/yast-in-container/wiki/Porting-YaST-Modules-to-Cont…
If you have any comments, questions just ping me.
If you have some tips or you want to add something, then do not hesitate
to edit the page, it's a wiki! ;-)
Ladislav
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
On 6/13/22 18:45, Jan Engelhardt wrote:
> On Monday 2022-06-13 18:16, Ancor Gonzalez Sosa wrote:
>
> # zypper in yast
> [...]
>
> 26 new packages to install.
> Overall download size: 11.5 MiB. Already cached: 0 B. After the operation, additional 27.6 MiB will be used.
>
> # zypper in podman
> [...]
>
> 9 new packages to install.
> Overall download size: 25.0 MiB. Already cached: 0 B. After the operation, additional 113.9 MiB will be used.
>
> So instead of having to install yast2 (zypper tells me 11 MB), I now have to
> podman (25 MB).
The outcome of those two commands heavily depend on the system you
execute them. What you show is the result in a traditional openSUSE in
which the software is delivered as packages directly installed in the
system (the paradigm I personally use and love). But that's not the only
reality we find out there nowadays.
You and me, who still enjoy the traditional model of Linux
distributions, will still install YaST directly in the system. That's
perfectly fine and will always be possible, of course.
But the new containerized YaST broadens the usefulness of YaST to also
cover other scenarios in which installing RPM packages is only done as a
last resort and containers are the preferred way to distribute and
consume software.
>> those new commands grab YaST and run it in a container that will
>> be transparently used to administer the host system.
>
> It's logically backwards that one is supposed to run Y2 in a
> container, only to have it go outside again. Containers are not
> supposed to affect the host system.
Actually privileged containers can affect the host system. And they have
existed for years. Isolating the base system from the software running
inside the containers is only one of the possible goals of containers.
In some environments, containers are the main mechanism to distribute
and execute software since they represent a way to bundle several
software pieces (traditionally RPM packages) in a self-contained format.
Now YaST is an option also in those environments. Although I expect YaST
to be used seldom there - basically to cover situations in which other
tools fall short in functionality or to ease transition for
administrators of traditional (open)SUSE distributions.
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Software Solutions
Dne 13. 06. 22 v 18:45 Jan Engelhardt napsal(a):
> So instead of having to install yast2 (zypper tells me 11 MB), I now have to
> podman (25 MB).
Of course, using containers is not for free, it needs some container runtime.
It depends what you already have installed in your system. If you already have Ruby
(e.g. because you develop a Ruby on Rails app) then the needed YaST size would even
go down. Similarly with podman.
But it seems that the future is in containerization of apps, so podman (or a similar
tool) will be very likely installed anyway.
> It's logically backwards that one is supposed to run Y2 in a container, only to
> have it go outside again. Containers are not supposed to affect the host system.
It depends what you want to do. Usually you want a container to work in isolated
environment. But running YaST in an isolated container (without host system
interaction) is pointless.
And there are already some other tools which run in a container but affect the host
system, e.g. the Portainer (https://www.portainer.io/) which is a Docker manager
running inside a Docker container managing the host Docker instance. So this approach
is not that unusual as it might seem on the first sight.
> So you have to widen the namespace to the point that it _is_ the host system,
> mounts included, at which point you could have just installed Y2.
Um, yes. But the point is that the YaST dependencies cannot collide with the system.
SLES still ships with Ruby 2.5, in theory the YaST container could use
newer Ruby 3.1 and we could use some new Ruby features there. And that applies to any
other used library.
Also the host system could contain even less packages, for example you do not need
zypper/libzypp in the host system, even rpm (!) itself is not required if you
run the YaST package manager in a container. (I have tested this in real!)
Another advantage is that you can get rid of YaST just with a simple
"docker/podman rmi" command and you can be sure it won't break any system
dependencies or uninstall something you actually need (like Ruby for your Ruby on
Rails app).
Containerization has both pros and cons. But we think the pros will be more important
in the future and the cons will be just minor issues or completely disappear....
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
On 13.06.2022 19:45, Jan Engelhardt wrote:
>
>
> So instead of having to install yast2 (zypper tells me 11 MB), I now have to
> podman (25 MB).
>
But if you already have podman but not yast ...
>
>> those new commands grab YaST and run it in a container that will
>> be transparently used to administer the host system.
>
> It's logically backwards that one is supposed to run Y2 in a
> container, only to have it go outside again. Containers are not
> supposed to affect the host system.
>
Ever heard about toolbox container for SUSE MicroOS?
What about firewalld container?
What about VPN containers?
And this can continue ...
Containers can be used just for application delivery, they are not
restricted to application isolation.
> So you have to widen the namespace to the point that it _is_
> the host system, mounts included, at which point you could have
> just installed Y2.
May be not often, but for one off task this could be quite handy. Or
read-only root where you simply cannot install anything ...
The YaST Team has been recently playing with a fun concept. What about
running YaST inside a container to manage a system without having YaST
or any of its dependencies installed? Turns out it works and we plan to
go further!
Learn more at https://yast.opensuse.org/blog/2022-06-13/yastless-yast
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
