Mailinglist Archive: yast-devel (87 mails)

< Previous Next >
Re: [yast-devel] Feedback needed! Hack Week project to re-define storage-ng API
On Thu, Feb 23, 2017 at 05:45:48PM +0100, Ancor Gonzalez Sosa wrote:

My Hack Week project is in that state in which all the important parts
work and now it's time to decide if it's worth investing a couple of
extra days to finish it all the way down.

Since the ultimate goal is to change how YaST interacts with storage-ng,
I would need the opinion of as many YaST developers as possible.

So please, please, please, take a look to this and give your opinion.

Some examples using the swig bindings directly can be better,

puts "Ptable type #{a_storage_msdos_ptable.type}" #=> Prints "Ptable type 1"

puts "Ptable type #{a_storage_msdos_ptable.to_s"


puts "extended" if [Storage::FsType_EXT2, Storage::FsType_EXT3,

puts "extended" if Storage.ext?(a_storage_filesystem)

Ok, ext? is new (part of my hackweed project). So far ext2 and
ext3 were not implemented.

ptable.type == Storage::PtType_GPT


Concerning the nil instead of exceptions:

a_y2storage_unused_partition.filesystem #=> nil

What happens here (nilclass exception?)?


I also thought about placing some classes in sub-namespaces but
mainly to resolve the upcoming name collision of DASD (the
"disk") and DASD (the partition table).

The most important question is - do you prefer the proposed approach and
API* or do you prefer to continue accessing directly to libstorage-ng
from YaST?

For me it will make programming in Ruby more difficult since I
have to know two APIs (already mentioned in doc/

ciao Arvin

Arvin Schnell, <aschnell@xxxxxxxx>
Senior Software Engineer, Research & Development
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups