On Monday 29 May 2006 15:57, Glenn Holmer wrote:

<shudder> Get rid of Mono! Using a platform designed for cross-OS compatibility to write OS-specific system tools is madness in any case.

zmd is not a required component. yast and zmd share the zypp resolver. Is true, if you want a cmd line client you need zmd. But yast can do the work if you don't need zmd features. zmd is a plus which give people wanting zmd enterprise one to many capabilities a straighforward path. Duncan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jdd wrote:

sorry if I'm completely OT, but I used urpmi on an other distribution, but don't ever see it mentioned here.

Is there a reason I missed?

For geeko's sake, jdd, you've pretty much managed to kill it. It's at least the 3rd hijacking on this single thread. Isn't it possible to a) stick with the one topic of the thread or open another one if it's OT b) if you don't know anything about the technical background of the topic, just stay out of it, ? You have no obligation to reply or comment on every single mail on the list. Thank you - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEe3E8r3NMWliFcXcRApZzAKCJjaW3hDTKPa7N+/aobQuw3GNIhgCeMEeQ Lpe4JcWsU8uELunv8Zo81Vo= =8tMB -----END PGP SIGNATURE-----

Dňa Po 29. Máj 2006 20:28 Duncan Mac-Vicar Prett napísal:

On Monday 29 May 2006 15:57, Glenn Holmer wrote:

...

<shudder> Get rid of Mono! Using a platform designed for cross-OS compatibility to write OS-specific system tools is madness in any case.

zmd is not a required component. yast and zmd share the zypp resolver. Is true, if you want a cmd line client you need zmd. But yast can do the work if you don't need zmd features.

zmd is a plus which give people wanting zmd enterprise one to many capabilities a straighforward path.

Just adding: the biggest issue with ZMD is the 1st stage of the installation, where we are running in very restricted environment, but we still need all bells'n'whistles of a package management available. Stano

On Mon, May 29, 2006 at 05:03:03PM +0200, jdd wrote:

may be better not advertise this before all the bugs are closed :-))

I disagree. Especially on this list we should look at the future. There are two processes. One is debugging or looking at the past. Another is features and looking at the future. Dragging this thread back to include bugs is not the way to go. It will suffocate the thread about current issues. Please don't go there. (No matter if the points are valid or not) Take it to another thread. <snip>

If I can make guesses from what I've seen, the only thing that lacks is a mechanism to add automatically inst-sources. One should be able to navigate to the server and clic "add".

Yes. That would be very nice for many.

then the command line tools.

there should be a very precise documentation on how to use all the tools available. much more than what is available now.

Yes. e.g. there used to be installation_sources. That seems to be gone. What is the replacement for it? Also other commandline things should be better documented. I asume I am not the only one who likes to do things on the command line.

Using "rpm" is already difficult. I have to use it any two month (approx) and each time I have to RTFM at least 1/2hour...

That is a bit over the top. I also use it very seldom. What I use is either `rpm -Uvh file.rpm` or `rpm -e program` Very seldom do I need anything else. I would not call that difficult. Just don't forget to follow by `SuSEconfig`. I think you are being unfair. On one side you complain about not having enough documentation. On the other side you complain that the documentation is too much. Do what I do. Make a file with small tricks that you sometimes use. and have a link to that file. That way the moment you need something you forgot, you can go to that file and see the little trick you used in the past.

May I also say that having 20-30Gb dedicated to a local inst-source server will not be a problem in a very near future, given the price fall of Hard drive storage, so a silent, low priority, background daemon to keep such repo uptodate would be a must.

Making that is not that difficult. Just rsync the directory. For installation sources, you only need to do it once. You then have everything you want. YOU should take care of the daily updates. The most important thing for me at this moment would be that I can use YaST also to download packages I install and that it make an installation source I can use. This means running createrepo or create_package_descr and do that in such a way that it does the signing automagicaly. The way I do it now is download things to /usr/src/packages/RPMS/*, do a createrepo and then use YaST to install it. At least for the stuff that is not on any of the installation sources. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Andreas Jaeger wrote:

Thanks Houghi - I agree with these points. We need to fix bugs and that's clear and discussed in far too many places - but we need to start thinking what can be done better for 10.2 and later.

sorry, but I have to desagree. Your can't ask us to talk of a broken system we can't have used. I don't ming to talk about bugs, only to have a working system to try it, judge it, see what is good what is not... jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi wrote:

On Mon, May 29, 2006 at 08:12:40PM +0200, jdd wrote:

...

sorry, but I have to desagree. Your can't ask us to talk of a broken system we can't have used.

Then please disagree in anothr thread. You will hold back development.

why can't you ever see some others people can have a different view from yours? You keep flaming anybody. I'm very patient, but sometimes you are really to much. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

Rasmus Plewe wrote:

And your different view is that your (generally correct) opinion about the current version belongs into a thread set up to discuss future versions?

as I understood it we where said "we are proud to announce"... the new version and we want to discuss. so I understand we must start from the current version and see how it can evolve. hence we have to know the current version... isn't it? and I accept happily any constructive remark, no need to be harsh (you where not)... if you read suse-linux-e you should understand at what point the "proudness" is questionned on that list... for example, we need badly a _fast_ system. With the current one, this seems unlikely. I try to find some issues (see my other post) we need at first, and as a minimum, know what is possible and what is not, not to talk in the void :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi wrote:

By getting back to the bugs you are high-jacking the thread and drawing away attention of what is asked.

I'm ready to try this wonderfull new car with no engine nor wheels... jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

Andreas Jaeger wrote:

I don't think we can ever end the discussion. I want to get some first comments back for our future development - and we'll keep on asking until the bugs are fixed and you can really use it...

If I judge from your previous posts, the main part of the debugging is already done and will be commited in a matter of days? but if you want, we can forget the actual 10.1 tests and look only at what we need as a package manager... Based, however, on what we know exists, I think that we need a monolithic package manager. monolithic, this is a "software management" module, replacement for "software management", "YOU", "add on products"... most of what is in the software menu of yast, because all these modules speaks of the same things. we need a module that starts immediately (no refresh at this moment). we _don't need_ (from a user point of view, of course) to know what is used (end of the yast/zen/rug...whatever discussion) As I see the point we have to add new software on the local catalog only when we add a new inst-source. At this point, and at this point only we should have the choice of refreshing the catalog. This catalog should know basically the software name, not the version of the software, so this part should be quite static. I think that in most situations the version info can be retrieved lately, in the background. In most cases, peoples needs only the current version. we need some kind of repository management. It's possible to have the same package on different repositories and we may need to use an older package for whatever reason. This is an exception from the previous stated system (ignoring the version), seldom used and so in cases we can afford to wait a little... We should have the option to store locally the packages already installed, or the packages _not_ installed, or both (or none), to make of then a cd/dvd set, for example as backup we should have the option to backup all what can't be installe with the package backup. That mean, in case of Hard drive failure, we reinstall with the package backup to have a fresh install, then restore the data backup to have a system similar to the previous one jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 houghi wrote:

On Mon, May 29, 2006 at 11:20:21PM +0200, jdd wrote:

...

but if you want, we can forget the actual 10.1 tests and look only at what we need as a package manager...

Thank you. bug solving belongs in another thread.

<snip stuff I agree with>

...

I think that in most situations the version info can be retrieved lately, in the background. In most cases, peoples needs only the current version.

What do you mean by 'in the background'?

jdd, please get a clue about how current package repository metadata formats are implemented (e.g. RPM-MD (yum)). The version info cannot be retrieved later, you first have to fetch a complete copy of all the repository metadata of all the repositories (aka channels aka inst-sources) you have configured. Then, and only then, a package manager's engine is able to compute the paths and operations for upgrading, installing dependencies, possibly removing packages because of broken dependencies introduced by upgrades, etc....

...

we need some kind of repository management. It's possible to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What's the problem with yast2 and rpm-md repositories ? We've had "repository management" since 10 years. If that's not what you meant, be more explicit.

...

have the same package on different repositories and we may need to use an older package for whatever reason. This is an exception from the previous stated system (ignoring the version), seldom used and so in cases we can afford to wait a little...

When the same package is present on different repositories.. that's what package managers are made for, they have algorithms to solve those "issues". Having to downgrade is a valid point though. That should be possible from the YaST2 Package Management screen as well.

How I see this happening is by saving what you download, not so much things you install from the CD or DVD, and save that in /usr/src/packages/RPMS/* for the full RPMs and wherever for the updates.

Well, if you're talking about downgrading, it's something that should be supported by the package manager. But it depends on the implementation of the package manager - wouldn't take for granted that zypp/zmd/rug (wherever the decision engine is implemented) is able to compute downgrades properly, it's a pretty different thing than upgrading packages. Smart is able to do that nicely. If the zypp/zmd engine can do that too, it would be useful to be able to downgrade from the GUI. A practical example: we 3rd party repository maintainers provide the very latest version of a lot of packages. Let me just take the example of gimp. Now, a user might want to try out the latest gimp package and upgrades using my repository. But then he either notices and issue (and informs me of that issue, hopefully ;)) or just notices that gimp release has a bug. In such a case, he would want to downgrade to the version that's shipped with SUSE Linux.

For the RPMs you either need to run createrepo or create_package_descr. Perhaps createrepo might be easier, because smart and the others can use it as well.

For the record: smart can also use yast2 repos (created with create_package_descr), as Mauricio Teixeira implemented that in smart. createrepo is _much_ easier to use than create_package_descr though, because in order to create a valid yast2 repository, there's all kind of black magic to do that's not covered by any tool (at least none that's available to us).

This means signing the packages and adding the directories to the apropriate places.

Signing packages is not mandatory, nor is signing repositories. If you trust the packages and the repository (which is very likely with a copy of RPMs you grabbed from a repository on the internet.. you trust in the first place ;)), just run "createrepo ." on the directory that has the RPM files (or its parent directory) and you're done. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEe3Vcr3NMWliFcXcRAuoFAKC85gH+edi/3q5Qkt0EZ3t9DKc1twCgk8bo Qe0uR4iAWoQz+BPR3LyD1/A= =1ro4 -----END PGP SIGNATURE-----

Dňa Ut 30. Máj 2006 00:27 Pascal Bleser napísal:

houghi wrote:

...

On Mon, May 29, 2006 at 11:20:21PM +0200, jdd wrote:

...

but if you want, we can forget the actual 10.1 tests and look only at what we need as a package manager...

Thank you. bug solving belongs in another thread.

<snip stuff I agree with>

...

I think that in most situations the version info can be retrieved lately, in the background. In most cases, peoples needs only the current version.

What do you mean by 'in the background'?

jdd, please get a clue about how current package repository metadata formats are implemented (e.g. RPM-MD (yum)).

The version info cannot be retrieved later, you first have to fetch a complete copy of all the repository metadata of all the repositories (aka channels aka inst-sources) you have configured.

Then, and only then, a package manager's engine is able to compute the paths and operations for upgrading, installing dependencies, possibly removing packages because of broken dependencies introduced by upgrades, etc....

...

...

we need some kind of repository management. It's possible to

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What's the problem with yast2 and rpm-md repositories ? We've had "repository management" since 10 years.

If that's not what you meant, be more explicit.

...

...

have the same package on different repositories and we may need to use an older package for whatever reason. This is an exception from the previous stated system (ignoring the version), seldom used and so in cases we can afford to wait a little...

When the same package is present on different repositories.. that's what package managers are made for, they have algorithms to solve those "issues".

Having to downgrade is a valid point though. That should be possible from the YaST2 Package Management screen as well.

...

How I see this happening is by saving what you download, not so much things you install from the CD or DVD, and save that in /usr/src/packages/RPMS/* for the full RPMs and wherever for the updates.

Well, if you're talking about downgrading, it's something that should be supported by the package manager. But it depends on the implementation of the package manager - wouldn't take for granted that zypp/zmd/rug (wherever the decision engine is implemented) is able to compute downgrades properly, it's a pretty different thing than upgrading packages.

Smart is able to do that nicely. If the zypp/zmd engine can do that too, it would be useful to be able to downgrade from the GUI.

A practical example: we 3rd party repository maintainers provide the very latest version of a lot of packages. Let me just take the example of gimp. Now, a user might want to try out the latest gimp package and upgrades using my repository. But then he either notices and issue (and informs me of that issue, hopefully ;)) or just notices that gimp release has a bug. In such a case, he would want to downgrade to the version that's shipped with SUSE Linux.

You can already downgrade a package: 1) start YaST package management module 2) choose a package 3) choose a "Version" 4) pick up a version you want, but make sure you mark the package to be "Updated" Stano

On Tue, May 30, 2006 at 10:02:35AM +0200, jdd wrote:

I don't remember having seen two package versions in yast or not recently

On my 10.1 I have e.g. speex and I have 6 versions that I can install. 2 x 1.0.5-12. One from FTP, the other from CD 4 x 1.1.12.0-pm-0. Two times i686 and two times i586. This from two different sources. The naming of the installation source should be done better, because I can not do anything with e.g. 20060524-074452 A date should be in the technical data of the file, not in the Installation source in the Version. But to answer your doubt: There is no problem to have two different package versions to choose from. If you don';t have that, it means your installation sources do not have different versions and even identical versions show up differently if they are there. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Tue, May 30, 2006 at 10:01:10AM +0200, jdd wrote:

AFAIK, there is no way (in 10.0) to manage repositories independantly (we can only add or delete one). When I see a package in Yast, I don't know from what repository it comes.

YaST, Software Management, Installation Summery. There you pick a package and look at Version. It is amazing. We try to work out things for 10.2 and you are dragging us back to 10.0. Is there realy no way to make you understand that we must look forward? -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Hi, jdd schrieb:

* oh... any way to make SuSEConfig faster? (old, very old problem, I beg no solution)

No generic one. You would have to look into each individual /sbin/conf.d/SuSEconfig.* file and try to optimize it. It's not easy because most of them are already optimized for speed. However, there are some ideas, IMHO running ldconfig after each transaction set shouldn't be necessary since every single RPM that needs it already runs it directly, this could maybe save half a second or so. Andreas Hanke

houghi wrote:

What do you mean by 'in the background'?

cron job? high nice? jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi wrote:

On Tue, May 30, 2006 at 09:40:43AM +0200, jdd wrote:

...

houghi wrote:

...

What do you mean by 'in the background'?

cron job? high nice?

Ah, ok. Something like YOU.

YOU is not so. I don't mean to do the hole job in the background, only updating the meta-data. I'm always reluctant to let the update be completely invisible, because it happen that these updates need some attention from the admin and a simple mail is not enough. I often delay an update (a little) to have the time to think at it. but updating only the meta-data file is completely unharming jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi wrote:

On Tue, May 30, 2006 at 03:29:46PM +0200, jdd wrote:

...

...

Ah, ok. Something like YOU.

YOU is not so.

I don't mean to do the hole job in the background, only updating the meta-data.

Ok, so something like the process that YOU is doing.

? do you mean when I lauch software install I have no more to sync the meta-data? this is not the way my computer works, alas. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi wrote:

No, I mean that you set YOU with YaST to get certain packages at a certain time. Also I am not saying it _is_ YOU. I am saying it is _simmilar_ to YOU.

OK. like this, quite true. It's also like some anti-virus system works on the concurrent system :-) dayly update, unnoticed if not by the logs. of course this won't work for the smaller connexions, so it's a solution for the people that have the less problems :-( but this could be enhanced. may be like the "look ahead" system of Mozilla. even with a slow connexion, one is sometimes online with little traffic (reading google...). At that time, using the connexion to update part of a file could be great. Is it possible? I don't know. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi wrote:

On Tue, May 30, 2006 at 05:10:51PM +0200, jdd wrote:

...

may be like the "look ahead" system of Mozilla. even with a slow connexion, one is sometimes online with little traffic (reading google...). At that time, using the connexion to update part of a file could be great.

Is it possible? I don't know.

Technically no problem. In dialup you just need to add a line at the end that if the connection is OK, you do the update.

it's a little smarter, it should know when the connection is up, when it's down and have a low priority. may be this can be in the ipup/down file as you said jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi <houghi@houghi.org> writes:

[...]

The most important thing for me at this moment would be that I can use YaST also to download packages I install and that it make an installation source I can use.

Why would this be usefull for a single machine? I understand that somebody adminstrating lots of machines might like it.

This means running createrepo or create_package_descr and do that in such a way that it does the signing automagicaly.

The way I do it now is download things to /usr/src/packages/RPMS/*, do a createrepo and then use YaST to install it. At least for the stuff that is not on any of the installation sources.

Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On 29 May 2006 at 19:51, Andreas Jaeger wrote:

houghi <houghi@houghi.org> writes:

...

[...]

...

The most important thing for me at this moment would be that I can use YaST also to download packages I install and that it make an installation source I can use.

Why would this be usefull for a single machine? I understand that somebody adminstrating lots of machines might like it.

Yes, I think it's very useful. I used to download patches only once, then update other computers using a CD with updates. Not everybody has a fast network connection all the time. Regards, Ulrich

On Tue, May 30, 2006 at 08:42:10AM +0200, Stanislav Visnovsky wrote:

Dňa Po 29. Máj 2006 18:15 houghi napísal:

[snip]

...

...

then the command line tools.

there should be a very precise documentation on how to use all the tools available. much more than what is available now.

Yes. e.g. there used to be installation_sources. That seems to be gone. What is the replacement for it? Also other commandline things should be better documented. I asume I am not the only one who likes to do things on the command line.

In 10.1, you should use 'rug' to add a new service. (Details: If the URL is not known to YaST, it will be added automatically when the source metadata are parsed for the first time by ZMD.)

rug sa --type=YUM ... services do not show in YaST because ZMD claims full and only authority on YUM repos. That you have to use --type=ZYPP is poorly documented. ;) Ciao, Marcus

Thomas Meindl <tom.meindl@gmx.at> writes:

Andreas Jaeger wrote:

...

With SUSE Linux 10.1 we have redesigned the way we handle software. We are proud to be able to announce our new software management backend which is based on the so-called library "libzypp" and which also integrates Novell's ZENworks technology.

That's a point that takes me aback. You all put so much work into the new package manager and its integration into 10.1 . Now there are some problems with it, and everybody rants about it (I'm too ;-)) - but I know that you are working on the issues and therefore I strongly believe that they will be solved soon.

...

In fact we are now able to manage more than packages only. We have integrated flavors like patches, patterns and even products all of which are defined and handled equivalently to packages. This new framework allows for new ways to define system dependencies and to build more complex application stacks also considering certain patch levels, patterns or even products to depend on.

What I really, really need is the possibility that all downloaded packages can be stored in a local repository on my hd. That's for several reasons: Fristly, I like to have a backup - in case of a broken distribution, I don't need to download all again (and again, and again). Secondly, this saves a lot of bandwidth and time. Thirdly, local repository can transferred to a media which can be used as a source for computers with no internet/ethernet connection... To make a long story short, I hope that zmd/rug gets some backup mode like it was integrated in YOU.

Now I understand Houghi's wish as well and understand it, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Bjørn Lie <bjorn.lie@gmail.com> writes:

Doesn't this exit now?

munin:/home/blie # rug set cache-cleanup-enabled False Preference 'cache-cleanup-enabled' changed from 'True' to 'False'

Does it work with service zypp? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Thomas Meindl <tom.meindl@gmx.at> writes:

Andreas Jaeger wrote:

...

With SUSE Linux 10.1 we have redesigned the way we handle software. We are proud to be able to announce our new software management backend which is based on the so-called library "libzypp" and which also integrates Novell's ZENworks technology.

That's a point that takes me aback. You all put so much work into the new package manager and its integration into 10.1 . Now there are some problems with it, and everybody rants about it (I'm too ;-)) - but I know that you are working on the issues and therefore I strongly believe that they will be solved soon.

...

In fact we are now able to manage more than packages only. We have integrated flavors like patches, patterns and even products all of which are defined and handled equivalently to packages. This new framework allows for new ways to define system dependencies and to build more complex application stacks also considering certain patch levels, patterns or even products to depend on.

What I really, really need is the possibility that all downloaded packages can be stored in a local repository on my hd. That's for several reasons: Fristly, I like to have a backup - in case of a broken distribution, I don't need to download all again (and again, and again). Secondly, this saves a lot of bandwidth and time. Thirdly, local repository can transferred to a media which can be used as a source for computers with no internet/ethernet connection... To make a long story short, I hope that zmd/rug gets some backup mode like it was integrated in YOU.

Now I understand Houghi's wish as well and understand it, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Agreed with most of Benjamin. One thing Id like to say is that Im not expecting this "design" of now to continue in 10.2, as you will have time to work on it, no need for a hack-ish solution, which is agreed by most people Ive asked, non suse people, zmd people, ppl who work in yast, etc. Im referring to the dual repositories synchronization situation, which is clearly a design chosen because of the lack of time due to the 10.1 release and the following sled/sles releases. So if you ask me for ways to improve the design, Id say to forget the way its done now and do the correct way, and not try to "make this one better", as its clear "wrong by principle" having the 2 side by side. Its like having an "official" and a 3rd party manager by default. Based on that draw ( http://files.opensuse.org/opensuse/en/7/78/Package-management-in-code10.png), the solution seems creating a zmd module to yast. At least, seems most logical for me, and yast PM then would no longer be acessing libzypp directly. Besides that, one would need to optimize the helpers and libzypp operation as it was already stated in previous discussions. thats my 2 bits Marcio Ferreira On 5/29/06, B.Weber@warwick.ac.uk <B.Weber@warwick.ac.uk> wrote:

...

One question we have is how the new tools rug, zen-updater and zmd compare to what we had before with YaST Online Update and suseWatcher. We are interested in every feedback ranging from architecture, design or used standards and their enhancements.

Going by

http://files.opensuse.org/opensuse/en/7/78/Package-management-in-code10.png the YaST package management talks straight to libzypp rather than zmd, while rug and zen-updater etc talk to zmd. Presumably this is where the synchronisation issues come from. The package management seems far more reliable when using just rug with yum repositories avoiding the synchronisation.

It seems clear the current situation with yast and zmd frontends working in different ways and synchronisation between them is not the way things should work. Presumably yast sw_single, YOU etc should become frontends to ZMD also. However, I am not sure whether this is possible, I have made my own frontend to ZMD and could not find a way to use the api from something other than mono (if there is please tell me :).

The user interface for package management and updating is also possibly one of areas requiring most urgent attention as this is how many users judge SUSE's package management. The yast sw_single interface is starting to show its age when compared with tools such as Adept and Synaptic (not that these are perfect either) and there is a complete lack of progress bars in the most important of places. There are some very good ideas in a file /usr/share/doc/packages/yast2-packagemanager/pkg-sel-ideas.txt from ~2002 which presumably were never implemented. The current interface does not cope well with multiple online repositories, not to mention the lack of progress bars while downloading large quantities of data. This will get more important still when the build service is completed and something like http://software.opensuse.org/download/repositories/ will be used. As for updating this is something I think windows does right. I think there should be a notification applet for updates and the user should not have to worry about the mechanics of where the updates are coming from or what updates to select (unless He/She chooses to). Oh and having deltarpms back would be nice.

Benjamin Weber

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

On 29 May 2006 at 23:27, houghi wrote:

On Mon, May 29, 2006 at 02:05:24PM -0300, Druid wrote:

...

Agreed with most of Benjamin. <snip>

Is it me or is this message coming in several times?

I had several duplicates as well.... Ulrich

Like I've mentioned before I think it's good to have Rug for Cli, Zen for Joe Six Pack and YaST for more advanced in depth packagemanagement. I won't comment on the backend setup - libzypp, zmd etc.

- Update in YaST is a mess. ....

I think there is a danger of thinking along the lines of how can we make the current situation less bad. SUSE has never had superb package management, new releases bring incremental updates which make the situation "less bad" (excluding 10.1). It might be time to take a step back and reconsider what the users need to be able to do and then how the technology should work to enable that. 10.1 introduced new technologies with potential, but even if they worked flawlessly it is even more confusing for users than the situation before. There is no point in having the most technologically advanced system if no-one is able to use it. Benjamin Weber

Marcus Meissner <meissner@suse.de> writes:

...

One question we have is how the new tools rug, zen-updater and zmd compare to what we had before with YaST Online Update and suseWatcher. We are interested in every feedback ranging from architecture, design or used standards and their enhancements.

It should be possible to disable and remove the whole ZMD stuff and still be able to work from commandline.

For this is missing:

- commandline installation source management (installation_sources equiv.) - commandline package installation (basically the yast -i pkg thing) - commandline online update (online_update equiv.)

I think the question here is even greater: Do we really need a daemon? Pros: + daemon helps with remote management + is fast (not the case with zmd if zmd is sleeping) Cons: + needs resources running (zmd needs less resources if it's sleeping) What else? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Volker Kuhlmann schrieb:

* Use delta rpms. Superb technology, why throw it out the window?

Rumours say that this will definitely come back and that the current lack of support for deltarpms is temporary. It was lost during the port of YaST to libzypp, but not thrown out of the window.

* Downloading >10MB of gziped repodata just to check what changed today is not really acceptable, and a killer for dialup. This also emphasizes the previous point.

This is mandated by the switch to repomd. repomd's design doesn't allow downloading only a subset of metadata because all metadata are stored in a single XML file. (It's actually not a single XML file, but the effect is the same as if it were.) Fixing this would require one of the following: a) Reverting the just introduced switch to repomd. Probably not an option. Or: b) Major modifications to the repomd standard. Not possible without a consensus between all parties that use it.

* Processes called *.exe look downright nauseating. It's silly to use too much extension for executables, the approach "it's called .xyz so it must be..." has caused Microsoft no end of grief. .exe has an unbreakable association with bad design and trouble.

Sorry, that doesn't really belong here. The usage of file name extensions is of course not specific to a certain platform.

At the very least, couldn't they call it .mono if they really thought they couldn't do better?

No, this would suggest that the assembly is specific to the Mono implementation of a CLI, which is not the case. Andreas Hanke

Hi, Marcus Meissner schrieb:

What about:

- cache the repodata. - download repomd.xml (very small) - check if cache is current by comparing the sha1sums.

Isn't that already the case? Correct me if I'm wrong. But the metadata would still have to be downloaded completely if the cache is not up-to-date. Andreas Hanke

On Tue, May 30, 2006 at 01:50:16PM +0200, Carl-Daniel Hailfinger wrote:

- have the repodata available twice: uncompressed and bzip2 compressed - first download gets the bz2 version - further syncs use rsync to update the repodata

No need to have it twice. If you use gzip you can make gzip to compress the data in a way that rsync works pretty well. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."

On Tue, May 30, 2006 at 02:08:24PM +0200, Carl-Daniel Hailfinger wrote:

I know that. But for the initial download, a bzip2 compressed file is likely to be much smaller than a gzip compressed file.

About 30% on that type of file. Do you think this is worth the effort to accept having redundant data in the repository with an additional risk of inconsistencies? Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carl-Daniel Hailfinger wrote:

Robert Schiele wrote:

...

On Tue, May 30, 2006 at 02:08:24PM +0200, Carl-Daniel Hailfinger wrote:

...

I know that. But for the initial download, a bzip2 compressed file is likely to be much smaller than a gzip compressed file. About 30% on that type of file. Do you think this is worth the effort to accept having redundant data in the repository with an additional risk of inconsistencies?

Yes. Because if it is done right, no inconsistencies can happen.

No need of pursuing down that path anyway, mandating rsync on mirror servers is a blocker ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEfMZ2r3NMWliFcXcRAqpkAJwPGjVmjxUAZzLMrCpZPKfrPJXryACfdIgo /RRvPB5uRxyc7IqYw5vNdt8= =Uj0I -----END PGP SIGNATURE-----

This is mandated by the switch to repomd. repomd's design doesn't allow downloading only a subset of metadata because all metadata are stored in a single XML file. (It's actually not a single XML file, but the effect is the same as if it were.)

Whatever the reason, it SUCKS. (And it's not nice without a progress indicator.) This is half a show stopper. I doubt any of my $RELATIVES on dialup are going to download >10MB every few days just to find out that a package they haven't installed was updated.

b) Major modifications to the repomd standard. Not possible without a consensus between all parties that use it.

Good scheme. An upwards-compatible way should be possible.

Sorry, that doesn't really belong here. The usage of file name extensions is of course not specific to a certain platform.

This thread is about what's annoying about the package management. .exe processes are. The .exe extension is specific to the mswindows platform (can one say of legendary notoriety?).

...

At the very least, couldn't they call it .mono if they really thought they couldn't do better?

No, this would suggest that the assembly is specific to the Mono implementation of a CLI, which is not the case.

?? Are there more Linux applications than mono which produce this .exe cr*p? If the executable is unspecific, why was an extension used at all? Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.

Andreas Hanke wrote:

Volker Kuhlmann schrieb:

...

This thread is about what's annoying about the package management. .exe processes are.

.exe processes are neither specific to the package management nor can they be influenced by the people who are designing the package management architecture for SUSE Linux.

So you say that the SUSE package management designers were forced to use mono .exe files regardless of whether it makes sense? Interesting conspiracy theory.

Try a Mono or, maybe even better, an ECMA mailing list.

Sorry, I googled for "ecma mailing list exe" and found nothing relevant. However, some sites seem to suggest .exe is not the only recommended suffix for .NET code.

...

The .exe extension is specific to the mswindows platform (can one say of legendary notoriety?).

No it isn't.

Examples please? (Except mono, which seems to be a reimplementation of windows-only .NET code. And no, being able to use wine for some .exe files doesn't make them cross-platform either.) Regards, Carl-Daniel -- http://www.hailfinger.org/

On Tue, May 30, 2006 at 05:28:20PM +0200, Andreas Hanke wrote:

Btw. try to remove the .so suffix from your libraries and the .py suffix from your Python modules in order to see how well Linux software works without filename extensions. Have a nice day, too,

That should be because of the the change in names, not because of the extentions. e.g. it is still SuSEconfig. Renaming it to the more correct name SUSEconfig will also cause problems. That does not mean that Linux can not work with a capital U. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Tue, May 30, 2006 at 05:53:18PM +0200, jdd wrote:

...

That does not mean that Linux can not work with a capital U.

how does mime-types works?

It 'should' be done with `file`: houghi@penne : file suse.mp3 suse.mp3: MPEG ADTS, layer III, v2, 32 kBits, 22.05 kHz, Monaural houghi@penne : mv suse.mp3 suse.txt houghi@penne : file suse.txt suse.txt: MPEG ADTS, layer III, v2, 32 kBits, 22.05 kHz, Monaural Unfortunatly most will ignore that (including me) and look at the extention instead. Not a real good idea, I think. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Wed, May 31, 2006 at 08:55:35AM +0200, Ulrich Windl wrote:

OTOH, Microsoft Windows (Outlook?) does that as well: If the file has any previewable suffix, the preview module corresponding to the "file magic word" (not the suffix) is called for "preview". Virus writers know that quite well.

I have no idea how M$ works, so I will believe you. I do not see any relevance however. I am not in this to either copy or be better then M$. I do not even care if what they do is better or worse then what Linux does.

Would you like your ".jpeg" to be executed as Perl Program?

If it is a perl program, then yes. houghi@penne : file create_package_descr create_package_descr: perl script text houghi@penne : mv create_package_descr create_package_descr.jpeg houghi@penne : file create_package_descr.jpeg create_package_descr.jpeg: perl script text

Despite of that, "file" can be wrong!

Yes it can. Just like a suffix. That does not mean that a suffix should never be used or is uninportand. It should be, in my eyes, only importand to the living person. It is nice to have a file.txt, file.sh and file.jpg so you know what to place where and what to open. To the system and programs using it, it should not be an issue. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On 30 May 2006 at 17:53, jdd wrote:

houghi wrote: [...]

...

That does not mean that Linux can not work with a capital U.

how does mime-types works?

case insensitive I think. Otherwise it would be a bug. Or was your question how "file extension to mime-types mapping" works? Case sensitive, of course. You'll see, a lower case 'U' would work in any case ;-) Regards, Ulrich

jdd

-- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

May I add a comment: * we need a speed indicator. That is a speedometer of the data repository. Some utility thats says wich inst-source is the faster. USB, DVD, Internet, ethernet 10, 100, gigs, there are so many choices and it's prety difficult to know which is the best (no to speak about the various internet mirrors) this is not trivial, because many factors are in the way, but even a inacurate one whould be better than none jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

* Ulrich Windl <ulrich.windl@rz.uni-regensburg.de> [May 31. 2006 07:59]:

where's the repodata DTD BTW?

The official ones for the repomd base format are at http://linux.duke.edu/projects/metadata/dtd/ The SUSE extensions are available as .rng files as part of the libzypp package: /usr/share/zypp/schema/yum Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

Marcus Meissner <meissner@suse.de> writes:

...

One question we have is how the new tools rug, zen-updater and zmd compare to what we had before with YaST Online Update and suseWatcher. We are interested in every feedback ranging from architecture, design or used standards and their enhancements.

It should be possible to disable and remove the whole ZMD stuff and still be able to work from commandline.

Why? What is the reason behind this?

For this is missing:

- commandline installation source management (installation_sources equiv.) - commandline package installation (basically the yast -i pkg thing) - commandline online update (online_update equiv.)

Do you like the user interface of rug, so would rug as *interface* work for you? Or is that broken? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Dňa Ut 30. Máj 2006 10:56 Marcus Meissner napísal:

On Tue, May 30, 2006 at 10:52:05AM +0200, Andreas Jaeger wrote:

...

Marcus Meissner <meissner@suse.de> writes:

...

...

One question we have is how the new tools rug, zen-updater and zmd compare to what we had before with YaST Online Update and suseWatcher. We are interested in every feedback ranging from architecture, design or used standards and their enhancements.

It should be possible to disable and remove the whole ZMD stuff and still be able to work from commandline.

Why? What is the reason behind this?

The most basic reason behind this is that ZMD is not integrated well with libzypp.

The whole "hack" with the helper binaries called and passing of critical data via strings is badly done at this time.

This 'hack' was always the way ZMD was using, even for libredcarpet. So, it's a hack as designed. Stano

Hello, Marcel Hilzinger wrote:

ZDM should run on rug, not vice-versa, as an additional feature.

That I do not understand. Do you mean: rug should use libzypp directly and zmd optionally?

I also like the new user management, so you do not need the root password for package installation.

I share the concerns of Marcus. Especially I see a distinction between: - allowing security updates / software installs (removal?) from the current repositories (with gpg check) and - allowing adding repositories, installing RPM files. Especially the first could be nice for semi-administrated computers. [The computer is administrated, but the local user may add some packages; he may not however, gain root access as the computer has complete NFS access.] To understand the full implications of the rights granted via ZMD rights is not obvious. Tobias

Marcel Hilzinger schrieb:

I also think, that removing the package manager from YaST is a good idea. yast and yast2 makes a lot of work.

Oh no, please don't even consider doing that! First, this is not possible at all because the YaST2 package manager is needed during the installation. Not having a full-featured package manager there is possible, certain other Linux distros do it that way, but IMHO this is a real plus of SUSE Linux over other distros and should not be dropped. Users should be able to customize their system right from the initial installation, a full-featured package manager is needed for that purpose. And second, the YaST2 package manager is so much more comfortable than other approaches that losing it would be a pity. It's not only comfortable, I'd almost call it "luxurious": - I don't know any other package manager that provides almost the same, familiar UI in console and graphical mode. - I don't know any other package manager that provides easy access to almost every information about a package, even including the %changelog. - I don't know any other package manager that provides a comparable interface for resolving conflicts. Most other implementations just offer removal of the conflicting packages instead of offering alternative solutions. No removal of sw_single, please.

With a good commandline tool, there is no need for yast-pm in console mode. It's too much work.

A rug-like commandline tool is substantially different from sw_single in console mode. sw_single provides the same UI that users already know from sw_single with Qt frontend, rug doesn't. Using sw_single in console mode, people who are familiar with sw_single's Qt frontend can repair a broken system (e.g., X unintentially uninstalled or similar) without getting started with something completely different first. Both should be provided. A rug-like commandline tool *and* sw_single for the console. Their purpose is so different that replacing one of them with the other is impossible.

Let's make (rug) the best commandline tool, and then give rug two frontend-families: zen-installer for newbies, (please one tool, not intstaller and remover) and zen-updater a new qt/gtk-frontend with full installation source management, selections etc

But why a new qt/gtk frontend if sw_single already exists? Implementing it with in a widget set for X would be a loss of functionality compared to sw_single, which already has Qt and curses frontends. And implementing it both for X and curses would be a duplication of effort already put into sw_single. I seriously disagree with the idea that a full-featured, quasi-graphical package manager that works without X is superfluous. Andreas Hanke

Marcel Hilzinger schrieb:

Not calling it YaST2 does not mean (hopefully), that there is no full featured package manager.

To work within the installation system, it has to be integrated with the rest of YaST in the same way the current sw_single is. Actually I don't really get the point here. Can I imagine the proposal as a rewrite of the YaST software installer? Why should such a rewrite be faster and lighter than the current sw_single? I doubt that it will be, if it uses the YaST framework, but it has to use the YaST framework at least for the installation system.

To make it simple and fast. It does not have to be new. But it has to be good and fast. Yast is fat, not fast ;-)

Yes, there are indeed lighter package managers than YaST's one, but they don't provide the same level of integration with the non-package management configuration utility of SUSE Linux, which is YaST. I propose to leave the implementation of lighter alternative package managers without YaST integration up to third parties. There are some upcoming ones. There is already a consensus that the package management stack of SUSE Linux needs a performance facelift, this will of course include YaST.

This means, that yast on console is additional work.

Maybe, but this one is really worth the effort IMHO. Just imagine a user trashing the GUI of his system by installing bad supplementary RPMs. Downgrading all packages to the version on the CDs is so easy with sw_single in a console and so painful with a real command-line utility, especially for people with little to no knowledge of how it all works. Having a curses-based software installer is a real plus IMHO. And of course the same point with the installation system applies here as well: A curses based package manager is needed to install SUSE Linux on systems where the hardware doesn't allow YaST to run in GUI mode. ;) Therefore it needs to be maintained anyway.

Did you use apt or smart? I never used yast on command line any more, when I got used to them.

Yes, I'm using smart every day, but I never use it in situations where a manual intervention is needed: - A dependency that is provided by multiple packages needs to be installed, let's say, one of multiple SQL plugins for Qt (smart is just "too smart" here and doesn't even ask which one the user wants to have) - A repository is broken, let's say, a necessary package doesn't build in supplementary, and the user prefers to fix it himself instead of letting an algorithm decide what to keep and what to remove (even the smartest algorithm can only try to guess, sometimes it will match the user's preference and sometimes it won't) A non-smart solution needs to be provided for such cases. sw_single is the perfectly non-smart solution, and it already exists, so please keep it. With Qt and curses frontends, of course.

So I see no need for yast package manager in console mode.

I couldn't disagree more. Killing that one would be a nightmare IMHO. Andreas Hanke

On Tue, May 30, 2006 at 01:47:20PM +0200, Marcel Hilzinger wrote:

...

And implementing it both for X and curses would be a duplication of effort already put into sw_single. It's not so simple. While all other YaST modules have the same code for command line and GUI, the package manager is almost coded twice (YaST developers please correct me, if I'm wrong). This means, that yast on console is additional work.

If that is the case, then coding should change in such a way that the developers only have to code once, like they do with other YaST modules.

...

I seriously disagree with the idea that a full-featured, quasi-graphical package manager that works without X is superfluous. Did you use apt or smart? I never used yast on command line any more, when I got used to them. So I see no need for yast package manager in console mode.

I use it on a semi-regurlar basis. e.g. when I ssh to my machine, I am using YaST in console. It looks like something I know. It gives me the full power of YaST.

Btw: Handle YaST in console mode is not as trivial, as it might seem. So new users eighter do not know about it at all or if the know, they will have problems to use the module.

It is also not so difficult so that users are not aware of how to use it. The only real problem I see is that a new user might not know that he needs to use the [TAB] to go from box to box. Furthermore a new user is normally not using theconsole mode. If he needs the console mode, he is still better off then without the console mode and just using command line. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Tue, 2006-05-30 at 11:40 +0200, Marcel Hilzinger wrote:

Reminds me of the unix-way-of-doing things:

we first need a fast, damn-good working command line tool. Then we can start about discussing and implementing GUIs for this command line.

ZDM should run on rug, not vice-versa, as an additional feature.

I also think, that removing the package manager from YaST is a good idea. yast and yast2 makes a lot of work. With a good commandline tool, there is no need for yast-pm in console mode. It's too much work.

Let's make (rug) the best commandline tool, and then give rug two frontend-families: zen-installer for newbies, (please one tool, not intstaller and remover) and zen-updater a new qt/gtk-frontend with full installation source management, selections etc

I also like the new user management, so you do not need the root password for package installation. You must also like MS windows with all of it's virii/worm spreading capabilities as that is what you are asking for here. What happens when you need to remove someone from being able to update software? I see no means of removing them from ZEN.

Security, security, security, security -must- always be number one when designing software. If people want something to run like "windows" tell them to install MS windows. -NOT- requiring the root password when installing software opens up a huge hole in security. Ken

Am Dienstag, 30. Mai 2006 14:22 schrieb Kenneth Schneider:

On Tue, 2006-05-30 at 11:40 +0200, Marcel Hilzinger wrote:

...

Reminds me of the unix-way-of-doing things:

we first need a fast, damn-good working command line tool. Then we can start about discussing and implementing GUIs for this command line.

ZDM should run on rug, not vice-versa, as an additional feature.

I also think, that removing the package manager from YaST is a good idea. yast and yast2 makes a lot of work. With a good commandline tool, there is no need for yast-pm in console mode. It's too much work.

Let's make (rug) the best commandline tool, and then give rug two frontend-families: zen-installer for newbies, (please one tool, not intstaller and remover) and zen-updater a new qt/gtk-frontend with full installation source management, selections etc

I also like the new user management, so you do not need the root password for package installation.

You must also like MS windows with all of it's virii/worm spreading capabilities as that is what you are asking for here. Never worked with Windows, so I don't know what you mean ;-) What happens when you need to remove someone from being able to update software? I see no means of removing them from ZEN. Then it's a design mistake of ZEN, which has to be corrected.

Security, security, security, security -must- always be number one when designing software. If people want something to run like "windows" tell them to install MS windows. -NOT- requiring the root password when installing software opens up a huge hole in security. You forgot, that installing without the root password is not the default. So root/the user has to add a user/himself. Security vs. usabiltity is a never ending theme, but that's not the most important one: Even more important than security is _choice_.

If a home user does not want to type the root-password each time he is installing a program, then this is his choice. -- Mit freundlichen Grüßen, Marcel Hilzinger Linux New Media AG Süskindstr. 4 D-81929 München Tel: +49 (89) 99 34 11 0 Fax: +49 (89) 99 34 11 99

Kenneth Schneider schrieb:

True, if you want a less secure OS use MS windows. If you want a more secure OS use linux

...

If a home user does not want to type the root-password each time he is installing a program, then this is his choice.

Then just login as root all the time.

Again, linux is not MS windows and should -not- be made to act like it.

Why do we need these Windows-Linux comparisons? Superuser capabilities are a genuine UNIX feature. There is nothing "MS Windows-like" in having an option to grant users certain permissions. It shouldn't be the default, of course, but nobody seriously proposes insecure defaults. sudo exists anyway, so I fail to see the point why having such an option in the software updater can be a problem. Educating people how to manage their systems is out of scope in this discussion IMHO. If someone wants to grant permissions, he will do it anyway, does it really matter if it's the classical UNIX tool named sudo or a built-in feature of the software updater? Andreas Hanke

Am Dienstag, 30. Mai 2006 15:30 schrieb houghi:

On Tue, May 30, 2006 at 03:02:49PM +0200, Andreas Hanke wrote:

...

Why do we need these Windows-Linux comparisons? Superuser capabilities are a genuine UNIX feature. There is nothing "MS Windows-like" in having an option to grant users certain permissions.

Those options are available. sudoers is just for that.

...

It shouldn't be the default, of course, but nobody seriously proposes insecure defaults. sudo exists anyway, so I fail to see the point why having such an option in the software updater can be a problem.

Because it is a job for sudoer, not for the software updater to add such a function. I very much dislike the fact that I am not asked for a pasword when I run updater. If it is not an automated job, I want to enter a root password each time I do something as root. Yes, each and every time. You can ad the root passwort each time, if you want. But why should other users not be able to leave this step out?

...

Educating people how to manage their systems is out of scope in this discussion IMHO. If someone wants to grant permissions, he will do it anyway, does it really matter if it's the classical UNIX tool named sudo or a built-in feature of the software updater?

Yes, that does matter. It is not up to the software updater. It is up to root to change sudoers. Yes. And that's how it works in 10.1. So I really do not see your problem...

-- Mit freundlichen Grüßen, Marcel Hilzinger Linux New Media AG Süskindstr. 4 D-81929 München Tel: +49 (89) 99 34 11 0 Fax: +49 (89) 99 34 11 99

On Tue, May 30, 2006 at 03:40:35PM +0200, Marcel Hilzinger wrote:

You can ad the root passwort each time, if you want. But why should other users not be able to leave this step out?

I click on the world and then on Configure. I can't find where to remove it. As I forgot how I got to this stage I did a new installation. This is what I get is the following: I see that there are updates available, so I click on it and then on Update. Either I add a privaleged user or I can click OK to accknowledge that I do not have the rights. If I click OK, I can't update. If I enter the rootpassword, I can always update. After entering the root password, I get: User was successfully added to zmd. The next time I am NOT asked for a password.

...

Yes, that does matter. It is not up to the software updater. It is up to root to change sudoers. Yes. And that's how it works in 10.1. So I really do not see your problem...

The "problem" I have is that people want to change it. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Wed, May 31, 2006 at 02:39:20PM +0200, jdd wrote:

houghi wrote:

...

On Tue, May 30, 2006 at 03:40:35PM +0200, Marcel Hilzinger wrote:

...

You can ad the root passwort each time, if you want. But why should other users not be able to leave this step out?

I click on the world and then on Configure. I can't find where to remove it. As I forgot how I got to this stage I did a new installation. This is what I get is the following: I see that there are updates available, so I click on it and then on Update. Either I add a privaleged user

how can you do it? I tried and was not asked to do so nor could find this in a menu (if we speak of the red/orange quotation mark in the tray)

I re-installed the system, did add a mirror, did not do the updates. This means that I have no updates. If you have updates, downgrade them. Then wait for the ball to become organge. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Wed, May 31, 2006 at 05:40:00PM +0200, Michael Loeffler wrote:

...

Question 2 is if you are allowed to say that it is based on SUSE or not. As of today usage of any Novell trademark is not allowed. But especially with the build service we are interested in customized distributions which are saying something like "based on" or "powered by" SUSE Linux. I am atm in contact with Novell legal to set up some rules how we handle this.

http://en.opensuse.org/Legal tells me that there is no Redistribution program yet. :-/ I asume you are talking about that now. Also there are things like OpenOffice.org (Novell Edition) that are on the OSS CD's and also other things that are customized. Are these affected as well? If yes, this would make them non-OSS. I hope they are still under GNU, meaning they are not affected. makeSUSEdvd now has a $MEDIA/info.txt that contains some sort of disclaimer and pops up with the 'Licence Agreement'. This media is not produced by Novell or SUSE. It is compiled with makeSUSEdvd available on http://en.opensuse.org/Making_a_DVD_from_CDs If you are not 100% sure of the origin of this medium, please go to http://openSUSE.org and download from there or buy the boxed set. If you want official support from Novell or SUSE, please use the official ISOs provided by them. If you trust the source where you got this DVD and are not botherd to get official support, then please have fun using this product and SUSE later. Unofficial support can be found via http://en.opensuse.org/Communicate -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Marcel Hilzinger wrote:

You forgot, that installing without the root password is not the default. So root/the user has to add a user/himself. Security vs. usabiltity is a never ending theme, but that's not the most important one: Even more important than security is _choice_.

one thing is sure. it's not so clear on Linux (at least for a self made man as I am) what can be done by admin groups. I think the normal way is to setup an "install" group and give it the rights. if it's like this that the utility works, no more problem for me jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

On Tue, May 30, 2006 at 10:53:08AM +0200, Andreas Jaeger wrote:

Marcus Meissner <meissner@suse.de> writes:

...

[...] - Also a update management system agnostic YOU watcher.

The old one just ran "online_update" and parsed its output. Only for the actual update it required the root password.

We could port the old one to run "rug", or whatever other equivalent.

The ZMD permissions handling is too permissive and too difficult to understand in my eyes.

So, what do you propose for permissions? Always root password for the update? I've seen positive feedback about needing the root password only initially when granting the permissions.

I am not sure and this is in the end more of a design issue... How much of the strict root <-> user seperation should be kept up? Because once you add "subscribe" and "install" privileges (like currently default proposed) for the user he has "root" equivalent rights. Which is very bad, since you do no additional credential checking afterwards. This would be exploitable by any malware that comes along, making it easier for Linux to become a virus heaven very similar to Windows. Currently any SL 10.1 with zen-updater with these rights is running the desktop as "root" user. Ciao, Marcus

Dňa Ut 30. Máj 2006 10:57 Pascal Bleser napísal:

Marcus Meissner wrote:

...

...

One question we have is how the new tools rug, zen-updater and zmd compare to what we had before with YaST Online Update and suseWatcher. We are interested in every feedback ranging from architecture, design or used standards and their enhancements.

It should be possible to disable and remove the whole ZMD stuff and still be able to work from commandline.

Indeed. rug is hardwired to ZMD though, AFAIK.

What's the added value of ZMD on 10.1, given that the resolver engine is in zypp anyway ?

The only advantage of having ZMD is to be able to manage SL 10.1 instances from Zenworks (for which you have to buy licenses from Novell). Or is there anything else ?

If that's the only real advantage, I consider it a pretty high price to pay, because it's a rather useless daemon running on the system. At the very least, it should be optional (and turned off on every SL installation when you didn't buy Zenworks).

Though another point is that rug mandates ZMD. Unfortunately rug is the only CLI tool to install packages on 10.1 (well, there's y2pmsh, which works but... it's the old engine ;)).

Other question: is there any particular reason for yast2 to use zypp directly instead of talking to ZMD [1] ?

[1]http://files.opensuse.org/opensuse/en/7/78/Package-management-in-code10. png

IMHO, it looks like either a) it's a hack b) it's necessary because there's no way to have yast2 talk to ZMD because ZMD is implemented with Mono c) both ;)

No, see Duncan's post and mine: ZMD is optional component and YaST needs a way to install packages in a restricted environment during the installation. Stano

Azerion wrote:

-If you select a package and click 'Install this', YaST must know is just have to install without showing the big window. Just a little progressbar with a detail-tab would be nice (and it must be tray-able).

look at the nice k3b sticked progress bar jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

-If you select a package and click 'Install this', YaST must know is just have to install without showing the big window.

Many users are used to the windows or macos way where you find an application,you download it and install it in some manner. Package management makes many things easier but is perhaps currently difficult for people to locate repositories containing programs they want, and add the repositories and then install the application. I propose that the user should not need to worry about these mechanics at all, and there is no need for them to have to do so. The package manager could provide two methods of installing software. 1: User can browse through "catalogues" of software, subscribe to projects he/she wants. It looks like this is well on the way to being implemented aside from a user interface for browsing available catalogues such as might be on software.opensuse.org. 2:User wants to install current version of $app, User visits $app's homepage, clicks "install on SUSE Linux" link and the program is automatically installed by the package management system. (after appropriate confirmation,authentication from user obviously) This second point seems relatively easy to implement, one has a file containing a selection of packages, description and a list of repositories where they can be found. The package management system can then interpret this file and add the repositories if required and install the packages with full dependency resolution. This method of installing packages would eliminate the user's need to know how to add package repositories, or what packages are on what repository. It would also enable users to easily install multimedia support by clicking a link on the packman website rather than having to follow instructions for adding a source and then installing the appropriate packages. Benjamin Weber

In Konqueror you can already do such a thing. Browse to an RPM, click on it and then select to install with YaST.

I am aware of this, this is not what I was suggesting at all. This method of installing a single rpm will only work if yast already has repositories containing all of its dependencies as sources. It is not a solution. Benjamin Weber

Then what you are sugesting is not possible, or at least not workable. You are asking that developers maintain their own repository. That won't happen, even if it might be very easy to do.

Not at all, of course they can do, and some might wish to. But all they would need to do is host a tiny file containing a list of packages to install their product and repositories they are available from. Who maintains the repository is irrelevant. The would not even have to do this, anyone could do it. Benjamin Weber

The developers of most software won't do this. Most likely they don't even know what repositries they need to add for each

I think there are enough possibilities for its use within the opensuse community to make it worthwhile by themselves. If it became popular more people would start using it.

So now I have to find out what repositories I must point people to for each version of SUSE. Naturaly this should then also be done for other distributions. Technicaly doable. In reality it won't work.

For packages in the build service at least it should be completely automatable, and for anyone it should be relatively trivial compared to the difficulty of packing

If you see how many deveopers only give you a sourcefile or just sourcefile and a *.deb, I doubt very much that they suddenly will start adding what you want.

Indeed, I wasn't suggesting that everyone would suddenly start using it overnight. I fail to see any downsides though, and it would solve a problem for users even if only adopted by current community members. However, should it be popular and adopted by others it could help far more.

The void is filled by repositories. The SUSE Build Server should be able to fill that void.

Indeed, but not everything can be hosted by this, both from practical and legal limitations. Something like I suggested would enable online software catalogues like http://klik.atekon.de/ and linspire's click n run for suse packages. - You agree it is technically possible. - There are projects that could immediately benefit from something such as this. - If this were available it /could/ be adopted by many (if it's not it can't) Expecting users to deal with adding additional repositories or even to understand what they are is not acceptable imho. What I think would be better to discuss are whether a) Is this technically feasible? b) Could it make things better for users Benjamin Weber

It is not the users you need to convince. It is the thousands of people who make the software and might not even use SUSE that you need to convince. Remember that many of them can't even bother to make an RPM package.

As I already said I believe something along these lines would be useful to users even if only used in conjunction with the build service and existing suse packaging projects. It would of course be even more beneficial if many people used it, but there is no way of knowing whether anyone would adopt it. I have pointed you at projects that have done similar things and been very successful, yet you still think it is unworkable. I suggested a solution to the problem that does exist of users downloading individual packages and not being able to install them. This may not be the best way of going about solving the problem but the problem does exist, and to users of other systems it makes package management seem worse than what they are used to. Prior to the mess in 10.1 the vast majority of the questions in #suse were how to add package repositories (often the user doesn't even understand why they need to), and how to install things like mp3 support, or win32codecs etc. Since january in #suse alone 761 people have needed to know how to add package repositories and, 568 people have asked how to install mp3 support. Do you have any ideas of alternative ways in which this problem might be solved, which doesn't involve users having to learn what repositories are and how to add them. Benjamin Weber

(this might start a different thread, so I chose to keep the thread but changed the subject) houghi wrote:

On Wed, May 31, 2006 at 07:31:42AM +0100, B.Weber@warwick.ac.uk wrote:

...

As I already said I believe something along these lines would be useful to users even if only used in conjunction with the build service and existing suse packaging projects. It would of course be even more beneficial if many people used it, but there is no way of knowing whether anyone would adopt it. I have pointed you at projects that have done similar things and been very successful, yet you still think it is unworkable.

The way you sugested it, it should be a solution for all $PROGS. I think that is unusable. Some projects will be able to pull it off. The majority won't.

That's what /you/ are saying ;)) The discussion is going more or less off-target, because what Benjamin actually means is the following: (let's take an example) - amarok developers release amarok 1.4.1 sources (of course, they don't do SUSE Linux packages themselves) - some packager from the openSUSE community (me, Packman, Novell KDE packagers, ...) makes SUSE Linux RPMs of amarok 1.4.1 - that packager sends the amarok devs a file that contains the data as described by Benjamin (see below) - the amarok devs put it on their website, in the download section (instead of just posting an URL that points to the download directory of the amarok RPMs for SUSE Linux); alternatively, they could post a link to that file on the actual repository server the packages are in Such an enhanced repository file could look like this: ---8<---------------------------------------------------------- [amarok] packages = amarok, amarok-xine repository-type = rpm-md repository-url = http://software.opensuse.org/.../@SLVERSION@/ ---8<---------------------------------------------------------- That would be the basic idea, as far as I understood Benjamin (we discussed a little about it on #suse). That's an idea to start with. It could of course be expanded to e.g. specifying dependencies that are not in the same repository - something like this: ---8<---------------------------------------------------------- [amarok] packages = amarok, amarok-xine repository-type = rpm-md repository-url = http://software.opensuse.org/.../@SLVERSION@/ dep-repository-type = rpm-md dep-repository-url = http://packman.../@SLVERSION@/ ---8<---------------------------------------------------------- What would be needed: - define a format (dare I say a "standard"/"specification") for those files - add MIME handlers for them (Firefox + Konqueror) that trigger a script that passes it to yast2/rug/smart/... - yast2/rug/smart/... first check whether they already have that repository in their list and, if not, they prompt the user for confirmation and then add it Actually this raises a few other points, such as: - canonical repository URLs: take the example of Packman and its many mirrors (or even SUSE Linux itself): to have package managers being able to recognize whether they already include a repository or not, they must be referenced using a canonical URL, and mirrors should be stored elsewhere/differently (smart is capable of doing this) - the Build Service already generates .repo files that can be added with smart (and probably with zypp... ?) so the "repository-type", "repository-url", "dep-repository-type" and "dep-repository-url" tags from the example above would most probably better point to .repo files: ---8<---------------------------------------------------------- [amarok] packages = amarok, amarok-xine repository = http://software.opensuse.org/.../@SLVERSION@/xxx.repo dep-repository = http://packman.../@SLVERSION@/packman.repo ---8<---------------------------------------------------------- Here's a (real) example for such a .repo file: ---8<---------------------------------------------------------- [KDE:Backports] name=A number of current KDE applications (SUSE_Linux_10.1) type=rpm-md baseurl=http://software.opensuse.org/download/KDE:/Backports/SUSE_Linux_10.1/ gpgcheck=1 gpgkey=http://software.opensuse.org/openSUSE-Build-Service.asc enabled=1 ---8<---------------------------------------------------------- Note that those .repo files can already be imported directly as smart channels: smart channel --add \ http://software.opensuse.org/download/KDE:/Backports/SUSE_Linux_10.1/KDE:Bac... We'd need to enhance them with mirror URLs, or add a link to another file with mirror URLs. As an example, I've written and added a patch to smart (that's included in my smart-0.41-25 package, onwards) to support embedding of mirror URLs in .channel (or .repo) files. The example above would look like this: ---8<---------------------------------------------------------- [KDE:Backports] name=A number of current KDE applications (SUSE_Linux_10.1) type=rpm-md baseurl=http://software.opensuse.org/download/KDE:/Backports/SUSE_Linux_10.1/ gpgcheck=1 gpgkey=http://software.opensuse.org/openSUSE-Build-Service.asc enabled=1 mirror=ftp://ftp.belnet.be/.../suse/.../download.../...10.1/ mirror=http://ftp.skynet.be/..../..10.1/ ---8<---------------------------------------------------------- smart is capable of "generic mirror matching", i.e. it can match URL substrings, e.g. http://software.opensuse.org/download http://ftp.skynet.be/mirrors/opensuse/software/download ftp://ftp.gwdg.de/pub/linux/opensuse/software/download The following URL: http://software.opensuse.org/download/KDE:/Backports/SUSE_Linux_10.1/bla.rpm would be automatically matched to the following mirrors: http://ftp.skynet.be/mirrors/opensuse/software/download/KDE:/Backports/SUSE_... ftp://ftp.gwdg.de/pub/linux/opensuse/software/download/KDE:/Backports/SUSE_Linux_10.1/bla.rpm Given such a possibility (smart is the only package manager capable of doing that atm though), let's rewrite the .repo file above: ---8<---------------------------------------------------------- [KDE:Backports] name=A number of current KDE applications (SUSE_Linux_10.1) type=rpm-md baseurl=http://software.opensuse.org/download/KDE:/Backports/SUSE_Linux_10.1/ gpgcheck=1 gpgkey=http://software.opensuse.org/openSUSE-Build-Service.asc enabled=1 mirrors=http://software.opensuse.org/download/mirrors.txt ---8<---------------------------------------------------------- And http://software.opensuse.org/download/mirrors.txt would be like: ---8<---------------------------------------------------------- http://software.opensuse.org/download http://ftp.skynet.be/mirrors/opensuse/software/download ftp://ftp.gwdg.de/pub/linux/opensuse/software/download ---8<---------------------------------------------------------- That would be quite trivial to implement with smart. Unfortunately, zypp/yast2/ZMD don't have such features (canonical repository URLs + mirrors, generic mirror matching) as of now, at least AFAIK. We'd also have to give some thought about such a mechanism and the newly introduced "secure installation sources" features in 10.1 (keys and ASCII-armored signatures on repository metadata have to match between the canonical repository and its mirrors).

<snip>

...

Do you have any ideas of alternative ways in which this problem might be solved, which doesn't involve users having to learn what repositories are and how to add them.

No, because repositories are still needed. What COULD be done is have

Benjamin never said it would replace repositories ;) It would just be an easier option to do "one click installation" (more or less) by also providing information about the repository the packages are available from. Currently, you just get URLs to the bare RPMs, which has the following shortcomings: - people should not directly install RPMs (with rpm -i) but use a frontend instead (yast2, rug, smart, apt-rpm, yum, ...), otherwise they'll get into "dependency hell" + they won't be notified of new versions - packages in one repository sometimes have dependencies to packages in other repositories (e.g. I have some packages that depend on some RPMs from Packman) Dependencies that can be resolved by package manager frontends themselves (and are provided in the same repository) obviously don't need to be included in that file.

something like .torrent on wich you click and the repo is to be added. e.g. http://packman.mirror.example.com/somedir/suse10_1.repo or repo://packman.mirror.example.com/somedir/suse10_1 if you just want to point to a directory with not much fuss.

Ugh.. what would be the point of using torrent ? No package manager I know is capable of downloading packages or repository metadata through torrent. Using torrent just to download such a .repo file is a huge overhead, HTTP or FTP would be much more appropriate (it's just a few bytes).

So make it easier for the repo's to be added. That might solve some problems, but not all.

It would definitely make package installation a lot easier for not so experienced users IMO. cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v http://www.fosdem.org http://opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 houghi wrote:

On Wed, May 31, 2006 at 04:06:10PM +0200, Pascal Bleser wrote:

...

- some packager from the openSUSE community (me, Packman, Novell KDE packagers, ...) makes SUSE Linux RPMs of amarok 1.4.1 - that packager sends the amarok devs a file that contains the data as described by Benjamin (see below) - the amarok devs put it on their website, in the download section (instead of just posting an URL that points to the download directory of the amarok RPMs for SUSE Linux); alternatively, they could post a link to that file on the actual repository server the packages are in

OK. This is something else what I did not get from Benjamin. It seems that we were mainly talking about the same issues: The developer won't do anything.

Right, and I don't see that changing all that soon, although the Build Service also tries to aim at that, directly, by providing a more-or-less easy to use web UI to create and manage builds for projects. The intention is also to provide that to software developers, so they can have their project releases hosted on the Build Service. In the end, though, packaging is really a topic on its own, that requires specific expertise and deep knowledge of the distribution. So either we will end up with developers hosting their package builds on the BS but needing/requesting support from packagers to enhance/fix their spec files, or it will still be packagers who make the whole build setup and process, more or less independently of the developers. Note that it's not a bad thing per se. As said, packaging requires specific know-how, so I think it really is a fine situation. What must be working well between the developers and their packagers (not just for SUSE Linux, also for other distributions) is communication. Releases and changes that can affect the build or installation (new config files, etc...) should be sent to the packagers, so they can integrate it appropriately and sometimes in a distribution-specific way. With what I'm writing now and in my previous mail, I'm considering that it's the packagers that do the packaging, not the developers. Maybe that will change at some point for part of the projects, but that's still hypothetical, so let's just consider it like that (packagers doing packages) as a "work hypothesis".

<snip> OK, I have already admited I don't know enough about XML, but is there a reason not to use XML? I asume (after reading below) because there already exists a .repo format.

Yes, there already are a few formats that suite those needs. Either they fit as-is (more or less those Build Service specific ".repo" files, or smart's ".channel" files - actually those .repo files look a lot like .channel files ;)), or need to be enhanced. But IMO it's better to use something that already exists and enhance it a little then to start something new and totally different. XML could be an option, and those files are (and will remain) very small anyway, but the parsing logic is very simple, so I don't think it's worth switching to XML.

...

What would be needed: - define a format (dare I say a "standard"/"specification") for those files - add MIME handlers for them (Firefox + Konqueror) that trigger a script that passes it to yast2/rug/smart/... - yast2/rug/smart/... first check whether they already have that repository in their list and, if not, they prompt the user for confirmation and then add it

That was also something i was directing at: <quote> e.g. http://packman.mirror.example.com/somedir/suse10_1.repo or repo://packman.mirror.example.com/somedir/suse10_1 </quote>

Ok, sorry, missed that one. The 2nd URL (repo://...) is also something I was about to write in my previous mail, but it doesn't work, as you cannot infer that the network protocol is always HTTP or always FTP (actually smart can even use sftp, dict or telnet, amongst others, with python-curl installed). Hence we must keep those URLs as... real URLs, including the protocol ;)

...

Note that those .repo files can already be imported directly as smart channels: smart channel --add \ http://software.opensuse.org/download/KDE:/Backports/SUSE_Linux_10.1/KDE:Bac...

So it already exists. It "only" needs to be included in YaST, libzypp and what not.

Not everything I wrote in my previous post works with smart at the moment, but the .repo files as they are in the BS right now work without modification, with smart. I don't know what zypp is able to do with those files ATM (possibly nothing), and whether there are plans to implement support for them or not. Could someone comment ? Adrian, Marcus, someone from the yast2/zypp team ?

<snip>

...

...

something like .torrent on wich you click and the repo is to be added. e.g. http://packman.mirror.example.com/somedir/suse10_1.repo or repo://packman.mirror.example.com/somedir/suse10_1 if you just want to point to a directory with not much fuss. Ugh.. what would be the point of using torrent ?

Please re-read. *Something like* . And as far as I can see *something like* that already exists. It is is .repo. Great, I just invented hot water and the wheel. :-)

Aaah, ok, now I see what you meant. Sorry, I misread ;)

So next step: put .repo support into YaST, ... (via browser or directly)

Right. It must be implemented directly, or through an add-on tool that parses and understands .repo files and then executes the necessary rug (or whatever) commands to add the channel. It could be implemented with a rather simple shell/perl/python script. Once that works, just add MIME handlers for .repo files that execute that script.

Thanks for all the extra info. It seems we were all thinking about the same thing.

Yes, definitely. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEfh2jr3NMWliFcXcRArM2AKC0zglM5DO1nkC8khoD6Aq7OQSuBQCfQiah nLKbGVry1dEOyFr7FYAkmGk= =WQ6B -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

houghi wrote:

On Tue, May 30, 2006 at 06:53:52PM +0100, B.Weber@warwick.ac.uk wrote:

...

...

In Konqueror you can already do such a thing. Browse to an RPM, click on it and then select to install with YaST.

I am aware of this, this is not what I was suggesting at all. This method of installing a single rpm will only work if yast already has repositories containing all of its dependencies as sources. It is not a solution.

Then what you are sugesting is not possible, or at least not workable. You are asking that developers maintain their own repository. That won't happen, even if it might be very easy to do.

if I understand well the thing, this will be solved (well, can be right now) by the build service. it's probably made for this in the first place :-) hold the source in the service and you'll ba able to have it compiled and packaged for SUSE Linux and most others distros. This could be a killer app for developpers, saving them a lot of work jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

houghi wrote:

On Tue, May 30, 2006 at 05:36:42PM +0100, B.Weber@warwick.ac.uk wrote:

...

2:User wants to install current version of $app, User visits $app's homepage, clicks "install on SUSE Linux" link and the program is automatically installed by the package management system. (after appropriate confirmation,authentication from user obviously)

This second point seems relatively easy to implement, one has a file

In Konqueror you can already do such a thing. Browse to an RPM, click on it and then select to install with YaST.

It should not be too difficult to make something like that for other browsers like Firefox to do the same.

In Firefox you click on an rpm and you are proposed to install with zen-installer. Vahis -- Sometimes I reply to top posters. Seldom. And usually just once. http://waxborg.servepics.com/English/Linux/SUSE.10.1/suse10.1.html SUSE Linux 10.1 Suomi: http://waxborg.servepics.com/Linux/10.1/suse-10.1.html

Is it really asked too much for a user to know how to install software?:

Yes

but some thinking before installing software is still required.

Indeed, the user needs to be presented with enough information to make an informed choice about whether or not he/she should really install it. However, this should not require the user to understand how the package management system works [insert obligatory car analogy here]. Especially when there is no technical reason that they should need to understand it in order to use it. Benjamin Weber

houghi wrote:

What happens is that people look for software, see a nice screenshot and want to install it and have no clue what to do with

the "Klic" system is for them jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

On Thu, Jun 01, 2006 at 08:23:23AM +0200, Ulrich Windl wrote:

I'm afraid that too much effort is put into making the last two categories of users happy, while in fact those are exactly the kind of users who won't be happy with Linux. They want the possibility to ruin their installation easily, and then they'll abandon Linux, because it's ruined. Or put simpler: Any cheap piece of hardware that doesn't work with Linux is a reason for not using Linux.

The reason for this is also easy. Instead of comparing Linux with M$, these users will compare a pre-installed system with a non-pre-installed system.

...

If it is possible, it would be nice as many users expect it.

Those with no ideas how things work frequently have odd expectations.

They are only odd, because you think they are odd. The request to have an easy way to install software is not odd at all. If many users can not figure it out you can do two things: 1) Say that all these users are idiots and do nothing 2) Listen and find a way to make it easy for these users. Read http://en.opensuse.org/Project_overview and guess wich one we should take. ;-) -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

* Andreas Hanke <andreas.hanke@gmx-topmail.de> [Jun 25. 2006 01:25]:

Hi,

continuing an old thread...

Andreas Jaeger schrieb:

...

As discussed last week, I wanted to continue the discussion about the package management changes - but not concentrating on the real bugs we're fixing now but on general issues:

Some thoughts:

1. libzypp does not offer the full functionality of the old yast2-packagemanager. A simple look at the file list of the old yast2-packagemanager RPM shows this:

/usr/bin/genIS_PLAINcache /usr/bin/installation_sources /usr/bin/online_update

online_update is gone and that's OK for me. rug replaces its functionality, and there are alternatives available. But the other ones are missing while needed: Their absense breaks the "Install package with YaST" and "Add directory as a YaST source" features of kdebase3-SuSE.

genIS_PLAINcache is probably obsoleted by createrepo.

Either this or use "rug mount" to directly access a directory of .rpm files.

But installation_sources is not: It would be very nice to have a replacement, a commandline tool for adding YaST sources that works independently of rug.

The ruby-zypp bindings are intended to fill this gap.

kdebase3-SuSE could be changed to use createrepo instead of genIS_PLAINcache and the installation_sources replacement.

Ideally, the installation_sources replacement would be called installation_sources and support the same commandline syntax as the old installation_sources.

Was the old tool and its options sufficiently useful ? How do they compare to e.g. rug or smart ?

In the case that this is not possible for whatever reason, wouldn't it be better to remove the two buttons "Install package with YaST" and "Add directory as a YaST source" from kdebase3-SuSE ASAP?

There's already a bug open for this.

2. rug/zmd and YaST/zypp communicate by executing each other. When adding a source to YaST, it executes rug to make sure that rug/zmd know about it. And when using rug/zmd to add a source, zmd executes various helper binaries from libzypp-zmd-backend.

Isn't that very complex and fragile per se?

Yes, it is indeed. :-( However, integration with the Mono 1.x environment forced this type of implementation.

Sure it's possible to fix bugs in this area until it works for most people, but will it ever be as integrated as the old solution without rug/zmd was?

No, probably not. Thats why we want to foster zypp-based applications which show a better integration.

Why does zmd access zypp by executing helper binaries instead of linking it directly, maybe through zypp-sharp bindings?

Because Mono 1.x presented some very high hurdles when linking to C (resp C++) libraries.

Why does YaST execute rug instead of having rug/zmd read the sources directly from zypp?

Sources (resp. Services/Catalogs in zmd speak) are handled differently within ZMD than within yast/zypp. A catalog (== yast 'source') is just one type of service in zmd. Additionally, zmd lives in a networked world with ftp or http(s) based catalogs, whereas YaST(zypp) support many more types (cd, dvd, nfs, smb, iso, ...).

Currently rug/zmd feel more like "added to the system and installed by default" rather than "integrated into the system".

Proper integration needs resources and experience. Novell has just started walking the 'integration path' for systems management.

3. In GNOME, RPMs are associated with zen-installer, which is fine. But zen-installer installs only one RPM at a time. Selecting multiple RPMs and installing them at once is not possible, but often needed to avoid having endless install -> check dependencies -> install loops.

Thats a bug and should be reported.

Knowing that the answer will be "People should not download individual RPMs and install them from nautilus, but add the installation source to YaST or switch to smart or apt", I still think that usability improvements should be considered in this area because more people have the habit of downloading individual RPMs than you might think.

We are listening, be assured. Klaus

Hi, Klaus Kaempf schrieb:

...

Ideally, the installation_sources replacement would be called installation_sources and support the same commandline syntax as the old installation_sources.

Was the old tool and its options sufficiently useful ? How do they compare to e.g. rug or smart ?

Yes, installation_sources was *very* useful for debugging and support purposes. One type of frequent problems in user forums are screwed up or incomplete YaST sources. installation_sources was ideal for identifying and fixing them because: a) It was much easier to handle than telling people "Go into YaST, call the installation sources module and type your installation sources here". A simple "Show me the output of 'installation_sources -s'" was sufficient; b) Its output was guaranteed to match the YaST configuration. This is not the case with rug because it is easily possible to configure YaST and rug in such a way that their sources are different, and the feature set of both does not match exactly. c) Similarly, telling people "In order to get multimedia working execute 'installation_sources -a http://blah.blubb/whatever/suse/10.0' as root" is much easier and faster to do than "Go into YaST, click here, click there, paste this into the first field and that into the second field" etc. rug is helpful for scenario c) only. And smart is even less helpful for these scenarios because it does not communicate with zypp in any way.

...

Why does zmd access zypp by executing helper binaries instead of linking it directly, maybe through zypp-sharp bindings?

Because Mono 1.x presented some very high hurdles when linking to C (resp C++) libraries.

Does this mean that better and tighter integration between zmd/rug and YaST, e.g. direct linking, is something that might happen with a future Mono release? Without knowing anything about the architecture, I guess that this might eliminate a possible performance bottleneck.

...

3. In GNOME, RPMs are associated with zen-installer, which is fine. But zen-installer installs only one RPM at a time. Selecting multiple RPMs and installing them at once is not possible, but often needed to avoid having endless install -> check dependencies -> install loops.

Thats a bug and should be reported.

After investigating a little bit, this seems to be a bug in GNOME or nautilus and not in Zen-Installer. Zen-Installer works just fine when passing multiple RPMs from the command line. The problem is that nautilus launches two separate processes instead of passing both files to one process when selecting two RPMs in nautilus. I will report this as a bug against the GNOME component.

We are listening, be assured.

This is highly appreciated! ;) Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org