Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
  • From: Lukas Ocilka <lukas.ocilka@xxxxxxx>
  • Date: Fri, 11 Feb 2011 10:22:08 +0100
  • Message-id: <4D54FFC0.6080309@suse.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 11.2.2011 09:00, Duncan Mac-Vicar P. napsal(a):
On 02/10/2011 03:55 PM, Josef Reidinger wrote:
> It looks like new mantra called "dynamic languages". I am not sure if
you ever try to handle such situations. Of course it is possible, but
then code become really messy and also horrible to maintain and test it....
consider module A which depends on module B,C,D,E ( e.g. storage,
language, time, bootloader and software management)

It is not about the language, it is about the design.

In YaST, every module uses functionality of another module and links to
it, instead of every module providing an implementation of a service.

So a module needs to install a package, in YaST, it imports packager,
which makes every module depend on libzypp. yast2 package is the
kitchensync where all the rest goes. Draw it and you get a spaghetti.

YaST should request "give a package installation implementation" and
handle gracefully the fact that there is none. Which is a much higher
level than catching a import error.

This might have a simple solution: The current YaST solution is
package-based because we still stick a bit to a package-owner model.
Each developer is responsible for a list of YaST modules.

To solve the spaghetti in a more elegant way, we would need

1.) Move functionality to one package
2.) Move UI to another package
3.) Have more task-specific functionality packages (such as studio_api*
used by SLMS - well done Pepo! ;))

... this applies to 'whatever the programming language is'

Lukas

* studio_api used to be part of SLMS in 1.0 and 1.1 but Pepa has
rewritten and moved it to https://github.com/jreidinger/studio_api
Since then, everyone can use it for their projects very easily.

- --

Lukas Ocilka, Appliances Department, Novell Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iD8DBQFNVP/AVSqMdRCqTiwRAkddAJ97NO+xFYSSIDqWc3TgV0G2cSTv1QCff9KM
9LH5JXfmgTBBPoSt6SEUQvk=
=6hpx
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread