houghi wrote:

On Wed, Apr 19, 2006 at 02:41:11PM +0200, jdd wrote:

...

what do you think of the idea (the setup is to be discussed after if necessary)

Say I find a spellingserror in SUSE 9.2. How do you propose that information is going to the users? It is not a security issue, so it won't be done by YOU.

YOU allows all king of updates, not only security, this is a user choice.

So what good would it be to do this?

Even worse for versions that are no longer in the security period (or how to call those two years). Say I find something and the solution for a 6.4 issue. How should I reach the users?

may be we won't go back so far :-)

Not via YOU. Not via any SUSE or Novell channel.

why not any SUSE??? and openSUSE??? why not an "update" openSUSE page?

in their policy. Security updates for 2 years.

I have problems now with 10.0, far inside the 2 years limit. and this don't seem to be fixed neither.

Sometimes major issues are also done, but by and large nothing else and especially not for unsuported versions.

It would send a very confusing message to the users if you say on one hand, we only do security updates and only support for 2 years and on the other hand give them spellings corrections and updates for older version.

no. We can update Yast (anyway, yast is the only SUSE visible products, all the rest have others maintainers).

For existing bugs, there is Bugzilla that can be used to post solutions as well.

? only patches available simply, that is pretty rare

So in general, I think it is a bad idea, sorry.

I think you are discussing methods, not ideas. Idea is: do you think community users can be part of the debugging that Novell employees can't do? if yes, then the methos will follow. emergency is for stable distribution, problem in previous ones should be very rare. may be SUSE is getting too fast, but the 10.0 if full of bugs, even annoying ones, 10.1 is quite bad on this respect as the RC1 don't works at all for some install options and this is not good. It really upset me to see typos in Yast I could correct in 10 seconds with the good interface staying there for age. may I write a wiki page saying "in this page there is a bug, but it wont be fixed"? I would like Novell programmers concentrate to bugs I can't fix (there are enough :-() 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

as an example of problems. I downloaded a yast source file (fr translation) got a 10.1 was looking for a 10.0 :-( probably my fault :-( install the rpm with yast. Was unable to find the unarchived files? used rpm2cpio yas... | cpio -i to extratct them... and I found no way to download all yast sources at once :-( if that ones where easily available, one could make a search and give much more relevant bugreports :-) 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:

I think I am completely misunderstanding what the issue is here. First it was about spelling errors that could be solved by users, then is was about changes that should be done in Yast and now it is about making better bugreports. Very confusing to me, sorry.

It's not really that difficult, houghi. What jdd is proposing/suggesting is that not only Novell solve the problems in the SUSE distribution, but that they open it (somehow) for others to participate with bugfixes (however minor or irrelevant). Perhaps I spot a problem in an apparmor profile - I can correct it, then submit a fix/patch. After all, this is usually the way OSS project work. Right now, opensuse seems to work mostly by the community submitting reports, and Novell fixing the problems. /Per Jessen, Zürich

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

houghi wrote:

...

I think I am completely misunderstanding what the issue is here. First it was about spelling errors that could be solved by users, then is was about changes that should be done in Yast and now it is about making better bugreports. Very confusing to me, sorry.

It's not really that difficult, houghi. What jdd is proposing/suggesting is that not only Novell solve the problems in the SUSE distribution, but that they open it (somehow) for others to participate with bugfixes (however minor or irrelevant). Perhaps I spot a problem in an apparmor profile - I can correct it, then submit a fix/patch. After all, this is usually the way OSS project work. Right now, opensuse seems to work mostly by the community submitting reports, and Novell fixing the problems.

I like the idea. I think part of the soluition is the build service coming soon. I think MySQL AB with the various products is a good example. They have internal source tree's and external. Whether they are BK(Bit Keeper) or svn. I am able to download and keep all the tree's locallly. I then get a pack and post it to the internals list or to the appporiate group/list. I have signed a form giving MySQL AB joint ownership of the code for them to do with as they like sometimes they change the patches sometime they take them as is. I would like something similar for All the SUSE Distribution. I think that is what will happend with the build service. All the source will be available to the build service and we can make/post fixes there. Then SUSE/Novell are free to take those changes and do with them as they like. I would like a public tree like public CVS access to freely down load all source and submit patches. I know with the 10.1 new accounts are held up. I asked for one back in January and I am still waiting. I would like to get on and fix a few of the bugs that really bother me. I like the opensuse-commits list. It is very interesting to follow. I sometimes wish there were more details. It is a very good start. Thanks, - -- Boyd Gerber ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFERtNUVtBjDid73eYRAomVAJwN2GV1uIpvdfkiec71MaKBPbpWaQCfVcpU GYQDpPQIGMnbOrah+MPFg7E= =qqyg -----END PGP SIGNATURE-----

I try to think of solutions. *may be we should slowdown and have a worked stable, a working unstable and a dev one like debian. Debian is too slow, but SUSE is too fast :-)

Yes, I think working in two teams: stable + unstable will be good. Unfortunately SUSE Linux 10.0 is poorly tested, leaving out many bugs. I'm even thinking about starting rolling Unofficial Service Packs for SUSE Linux 10.0. (why only corporates deserve fixes ? we - the community - too deserve fixes) I also believe that offline support must be available for stable releases - that is either Service Packs (like M$) or ISO releases (r1, r2 - like Debian Stable).

*I already tried to identify what yast module do what to look at the sources. It's really difficult. any doc?

*why is Yast so bad documented? I use SUSE now for nearly 10 years an they are still options I don't know what they are for...

Yast is generally very poorly documented, and there are very few tutorials about programming Yast modules (even the FOSDEM2006 tutorial is not really enough to start speaking Yast ) I think Novell should release more documentation about Yast - so then more developers will write Yast Modules and perhaps more distros will use Yast (which in turn will bring us even more modules backported from other distros).

On Wed, Apr 19, 2006 at 08:04:00PM +0200, jdd wrote:

...

It is not a security issue, so it won't be done by YOU.

YOU allows all king of updates, not only security, this is a user choice.

I understand that YOU could do any updates. It is the policy from SUSE to only do updates. The reason has been explained before. <snip>

I have problems now with 10.0, far inside the 2 years limit. and this don't seem to be fixed neither.

Is it a security issue? If so, it should be reported via Bugzilla, if not, it might not be importand enough to be done.

no. We can update Yast (anyway, yast is the only SUSE visible products, all the rest have others maintainers).

YOU can indeed do it. It is the policy of SUSE only to do security updates.

...

So in general, I think it is a bad idea, sorry.

I think you are discussing methods, not ideas.

The two are inter connected. If you have an idea, you also need the method to do the updates.

Idea is: do you think community users can be part of the debugging that Novell employees can't do? if yes, then the methos will follow.

Bugzilla is great for this. <snip>

It really upset me to see typos in Yast I could correct in 10 seconds with the good interface staying there for age.

Again, SUSE does security updates, not spellingcorrectionupdates.

may I write a wiki page saying "in this page there is a bug, but it wont be fixed"?

Sure, it is a wiki. You could make it yourself easy and just say that only security updates are done and spelling errors are not done.

I would like Novell programmers concentrate to bugs I can't fix (there are enough :-()

So again I ask you, say you have found a spellingserror, how would that get to me, a user, when you know it won't be done by YOU? houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

On Wed, Apr 19, 2006 at 09:37:21PM +0200, Per Jessen wrote:

Eventually yes, but not both at the same time. When John F. Kennedy thought going to the Moon was a good idea, he didn't quite have the methods ready. The methods will follow if the idea is accepted.

Bush told that going to Mars with a manned vehicle was a good idea. That won't happen in the timeframe he promised. At the time of the JFK speech, the idea was already accepted and the method needed finetuning. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

On Thu, Apr 20, 2006 at 03:08:27PM +0200, Per Jessen wrote:

...

Bush told that going to Mars with a manned vehicle was a good idea. That won't happen in the timeframe he promised. At the time of the JFK speech, the idea was already accepted and the method needed finetuning.

Oh yeah - about 8 years of it, wasn't it? I think what you call finetuning I prefer to call development.

So let us see how much development will be done with the Bush speech and his speech about a manned-mission to mars. What I am saying is talking the talk is not enough. The one can not go without the other. I would not call it development, I would say 'further development'. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

On Thu, 20 Apr 2006, jdd wrote:

...

So again I ask you, say you have found a spellingserror, how would that get to me, a user, when you know it won't be done by YOU?

why do you keep saying things you should know are wrong? YOU is _not_ only for security. Novell choosed to not bugfix other than security, for evident reason (they concentrate on 10.1), bugzilla bugreport on other subjets are prone to be rejected.

The YaST Online Update has been used only for security and critical updates in the past -- but there is no technical reason not to use it for other/minor stuff, but we have choosen not to do this in the past. This has been discussed many times on this list, so please let's try not to get into this again now.

others contributors understood my meaning;

The yast example I gave was to show that right now it's very difficult to install yast sources locally. tgis kind of install could be a way to give not only bugreports but also bugfixes through bugzilla.

I hope the new build service will be able to do part of what I aks for.

It definately will. Regards Christoph

On Thu, 20 Apr 2006, jdd wrote:

...

The YaST Online Update has been used only for security and critical updates in the past -- but there is no technical reason not to use it for other/minor stuff, but we have choosen not to do this in the past. This has been discussed many times on this list, so please let's try not to get into this again now.

I quoted on an other mail (sorry, I have not it at hand) that anybody can see in YOU three levels of colors, with "optional" patches.

right now I see "SuSE Kde extensions" (SuSE written that way :-) "This update fixes problems with buttons being swapped in QMessageBoxes when the Qt/KDE integration is enabled."

this don't seems security related

but this is minor; it's easy to find solutions

Ok, I should have phrased it like this: "... we have choosen to release other/optional/minor updates as an exception only." However, with the power of the openSUSE build service, we as a community might come to the conclusion that it actually makes sense to create a repository with fixed packages that covers all those littel bugs and glitches that you find while using the distribution. But it should be obvious, that something like this needs quite an effort by the community. Regards Christoph

Hi, On Thursday 20 April 2006 09:26, Christoph Thiel wrote:

Ok, I should have phrased it like this: "... we have choosen to release other/optional/minor updates as an exception only." However, with the power of the openSUSE build service, we as a community might come to the conclusion that it actually makes sense to create a repository with fixed packages that covers all those littel bugs and glitches that you find while using the distribution. But it should be obvious, that something like this needs quite an effort by the community.

And that was the original proposal (if I understood it correctly). What would be needed would be a clear communication towards the end user: a commitment from SUSE limited to security and major issues (todays policy) and beyond that a non-commited "community contribution". Greetings from Stuhr hartmut -- Hartmut Meyer, NTS EMEA Partner Relationship Manager SUSE LINUX GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 421 3064385 - M: +49 179 2279480 F: +49 421 3064387 - hartmut.meyer@novell.com ---------------------------------------------------- http://www.novell.com/open

On Thu, Apr 20, 2006 at 01:41:04PM +0200, jdd wrote:

* true maintainer. I don't really know how Novell/SUSE is organised, but I beg there is a team or a person assigned to a task. For example I see this: <snip> and I beg Pat is the owner of this package.

May be a member of the community could be set as the maintainer, or simply set as a Pat help

Everybody is a 'Pat help'. Just use Bugzilla and add her as a contact, or mail her directly. The first will be better, I suppose. If you can't find the correct person, most likely the person at SUSE you assigned it to, will know and assign it to that person.

* organised help.

Simply better document the way the community can help.

Make that 'better documentation in general'. Although the documentation is one of the best for the users. There still needs a LOT to be done. Fact is that good documentation takes time away from development and 99% of the documentation is not read.

Make a wiki page explaining how to download the po sources,

I believe the po files are in the sources so they are available. Each package will have it's own .po files. Placing them outside of tat package might be complicating thing, although I am not sure.

make all these po files available from an html browser (seems very easy).

file:///dir/to/langage.po after unpacking the po file, I should think. Lets try it. I did a `locate *.po` and got (among others) /usr/share/gfxboot/themes/SuSE/po/nl.po, so that would become: file:///usr/share/gfxboot/themes/SuSE/po/nl.po

Make wiki pages with yast screenshots and links to the relevant po file. Eventually provide special bugzilla access for that.

I would call that a bit over the top, especially because you need to replace the screenshots after each correction to be accurate. However as it is a wiki, please go ahead. <snip>

in fact, if I correctly see, this is nothing more than a building / bugfix system for documentation/translation... <snip>

It feels as if you try to re-invent bugzilla again or that you want to become an offical SUSE maintainer. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

Karl Eichwalder wrote:

Reading old mails...

jdd, I like your idea about polishing the distribution once the product is released.

:-) As Christoph and others said, we now can offer those

updates using the openSUSE Build Service. If not already done, I propose to start a "translation" Project and to add some yast2-trans packages for testing. Is "translation" ("Translation"?) a good name? What about "L10N"? "Localization"?

why not? for example is going from pt to pt-br a translation? localization seems good.

The packages will require some adjustments to make them build smoothly outside of our internal SVN system. More precisely, building works, but for best results preparation steps are required which are usually done within the SVN. This part we will move to the developer.novell.com servers some time soon. For preliminary information, see http://en.opensuse.org/OpenSUSE_Localization_Guide

I wont be able do do any usefull work on this project before end of summer (I don't take vacations, but family is very demanding at this period :-); this said, using svn if probably the best way to make such small adjustement. We could have some kind of project manager (people able to manage svn) from the local voluntaries to keep the doc up to date - a wiki is definitvely not the place for that

All this could be better discussed on the opensuse-translation ML, to where I'll forward the translation aspect of this thread. Please subscribe to the opensuse-translation ML!

why not use doc? there are too many lists already. sight. (I subscribed)

jdd writes:

...

in fact, if I correctly see, this is nothing more than a building / bugfix system for documentation/translation...

As you see, I think the documentation at large is that part where the community can be the most usefull, because anybody can proofread a screen.

Yes, the same could be done for documentation, but do not underestimate the work involved...

I don't :-) I was an editor, long time ago but as soon as some tasks can be scripted things a simpler (a little) 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-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

On Thu, Apr 20, 2006 at 12:46:23PM +0200, Pascal Bleser wrote:

To keep it limited to an update-only notification tool, it could only notify the end-user when an update to an already installed package is available from any of the registered installation sources. That wouldn't be all that complex to implement (and the user could choose/configure whether he wants to be notified about new packages as well or only about updates).

As long as the package had the feature to or wil only update those from the original source, I would be very happy to use it. e.g. if there I have a xmms installed from SUSE and there is a newer version on Packman, I want to keep my SUSE, or the other way around. On the `smart` thing. If it is so much better then the YaST software management, why not ditch the seconds and replace it with smart? It should not be too hard to make a YaST module. Could/should be doable for 10.2 houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

Henne Vogelsang wrote:

Its included in "our" enhanced rpm-md that we use for the update dirs.

uh :-) open source is a dreadfull system :-) users asks always questions and secrets are hard to keep :-)))) I know openSUSE is only 9 month old, it's VERY youg. We all want the best and so push the beast :-) But we know a great job is done :-) 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, 20 Apr 2006, Pascal Bleser wrote:

You are mixing up two different things: 1) using YOU as a channel to provide other updates, not only security or critical ones 2) access to the sources of the packages on SUSE Linux

I'd just like to mention for the 1st item that this totally voids the YOU approach in my opinion, from the perspective of a 3rd party packager. Patch RPMs aside (too complex and time-consuming to maintain), YOU is just a notification mechanism. There is no reason for it to be a separate channel for getting RPMs (well, there is one reason, read at the end ;)).

I think that the concept should be refined here, if we head in the direction of having broader updates on released SUSE versions and real integration of 3rd party packagers, something that has been totally ignored in the past.

Using/accessing additional package repositories has been a feature of YaST for quite some time already -- however, creating those repos was challenging in the past, due to the lack of proper documentation for example. I think we have made significant progress in this area with 10.0 (which introduced support for repomd/yum repos) and especially with 10.1 (which may sound a bit exaggerated, considering the current state of libzypp -- but at the end of the day, it still improves the repo handling a lot ;)).

YaST2 should also get a decent way to update existing packages. This is currently (as of 10.0) a real pain to do, there's no obvious option. You have to select "package categories", go to "zzz all", right click on the right pane, "this list..." -> "update if newer version available". It's too complex, there should be a single icon in the YaST2 menu to do that operation in a dedicated way, since it's what almost every SUSE Linux user is doing, every single day for many of them.. well, at least those who use 3rd party repositories like mine, Packman, etc...

Offering an update repository (in repomd style + patch infos) should pretty straightforward on 10.1...

And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".

"smart update && smart upgrade" is so much easier, it's what I recommend to everyone.

Exactly -- y2pmsh is basically dead, so pushing people into the smart direction is the right thing(tm) ;)

Doing that with YaST2 would be a much more tedious operation: - adding 2 installation sources (the GUI should really accept URLs instead of splitting into "protocol", "server", "directory on server", what a pain)

+1 -- should be fixed for 10.2 ;)

- make sure they're on autorefresh

Which sould actually be the case by default, IIRC.

Now, to come back to YOU... The only real added value of YOU is the following additional information: - description of the update - severity (critical, security, minor, ...)

Have you looked at the new update trees for 10.1? They contain repomd stuff out-of-the-box + the additional information is stored in a repomd-alike way, which could be created by 3rd party packagers as well. I think it could even become a feature of the openSUSE build service to create/provide special update trees or add those kind of additional information to repos it creates. (But that's something for... later ;))

That information is not available in repository metadata formats as of now (neither in YaST2, nor apt-rpm, nor rpm-md and I guess it's not possible in red/open-carpet either).

That's the problem ;)

An update/change description could be pulled out of the RPM %changelog, although I don't know whether that information is stored in current repository metadata formats like rpm-md.

But the severity information isn't available by any means.

See above -- the stuff we did for the update trees is quite an extension to what repomd offers right now, but it should be relatively easy to add this to smart and $other_packages_manager(s). Regards Christoph

Christoph Thiel wrote:

On Thu, 20 Apr 2006, Pascal Bleser wrote:

...

You are mixing up two different things: 1) using YOU as a channel to provide other updates, not only security or critical ones 2) access to the sources of the packages on SUSE Linux

I'd just like to mention for the 1st item that this totally voids the YOU approach in my opinion, from the perspective of a 3rd party packager. Patch RPMs aside (too complex and time-consuming to maintain), YOU is just a notification mechanism. There is no reason for it to be a separate channel for getting RPMs (well, there is one reason, read at the end ;)).

I think that the concept should be refined here, if we head in the direction of having broader updates on released SUSE versions and real integration of 3rd party packagers, something that has been totally ignored in the past.

Using/accessing additional package repositories has been a feature of YaST for quite some time already -- however, creating those repos was challenging in the past, due to the lack of proper documentation for example. I think we have made significant progress in this area with 10.0

Actually I meant a little bit more than adding other repositories. Everything, up to 10.0 was only tailored for the way SUSE ships its distribution, and didn't take into account how the actual setup for many (I wouldn't say "most", I don't have numbers) users is, i.e. with additional repositories such as Packman and a few others. And, precisely, lack of documentation has been a major issue, for example - how to create a YaST2 repository (which is still a mess, compared to opencarpet or createrepo - I won't mention apt4rpm as I've always found that to be way too complex to set up as well) - how to create YOU repositories - easy "upgrade" operation in YaST2 (the "system update" thing in YaST2 always reinstalls the kernel package)

(which introduced support for repomd/yum repos) and especially with 10.1 (which may sound a bit exaggerated, considering the current state of libzypp -- but at the end of the day, it still improves the repo handling a lot ;)).

I hope so ;)

...

YaST2 should also get a decent way to update existing packages. This is currently (as of 10.0) a real pain to do, there's no obvious option. You have to select "package categories", go to "zzz all", right click on the right pane, "this list..." -> "update if newer version available". It's too complex, there should be a single icon in the YaST2 menu to do that operation in a dedicated way, since it's what almost every SUSE Linux user is doing, every single day for many of them.. well, at least those who use 3rd party repositories like mine, Packman, etc...

Offering an update repository (in repomd style + patch infos) should pretty straightforward on 10.1...

Great! Where can I find the documentation about it ? - how to generate such repositories, where does the additional data come from ? - what are the repomd extensions ? schema or DTD ? Is it backwards compatible with plain repomd ?

...

And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".

"smart update && smart upgrade" is so much easier, it's what I recommend to everyone.

Exactly -- y2pmsh is basically dead, so pushing people into the smart direction is the right thing(tm) ;)

y2pmsh is still well alive for 10.1 atm, unfortunately, because libzypp & friends are mostly broken in 10.1RC1 :\ (at least that's what most people report on IRC, I for myself currently use y2pmsh for my 10.1RC1 build chroots) Which makes me think that... err... once y2pmsh will really be dead (i.e. non functional), y2pmbuild must be ported to something else. To smart ? Or is there some form of CLI driven package installation tool with libzypp ?

...

Doing that with YaST2 would be a much more tedious operation: - adding 2 installation sources (the GUI should really accept URLs instead of splitting into "protocol", "server", "directory on server", what a pain)

+1 -- should be fixed for 10.2 ;)

Good :) I guess it should be entered in bugzilla.

...

- make sure they're on autorefresh Which sould actually be the case by default, IIRC.

Yes, but also setting the internet installation source for SUSE Linux (inst-source and inst-source-java) on no-autorefresh.

...

Now, to come back to YOU... The only real added value of YOU is the following additional information: - description of the update - severity (critical, security, minor, ...)

Have you looked at the new update trees for 10.1? They contain repomd

No.

stuff out-of-the-box + the additional information is stored in a repomd-alike way, which could be created by 3rd party packagers as well.

I sure hope so ;)

I think it could even become a feature of the openSUSE build service to create/provide special update trees or add those kind of additional information to repos it creates. (But that's something for... later ;))

Right.

...

That information is not available in repository metadata formats as of now (neither in YaST2, nor apt-rpm, nor rpm-md and I guess it's not possible in red/open-carpet either). That's the problem ;) An update/change description could be pulled out of the RPM %changelog, although I don't know whether that information is stored in current repository metadata formats like rpm-md. But the severity information isn't available by any means.

See above -- the stuff we did for the update trees is quite an extension to what repomd offers right now, but it should be relatively easy to add this to smart and $other_packages_manager(s).

Hm. myeah. Well, if that "repomd-suse" format is backwards compatible with plain repomd, it will work with smart and yum without any need for modifications (I suppose). If not, then support for another SUSE-specific repomd-variant must be added to smart. Mauricio ? ;) cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels

Christoph Thiel wrote:
> On Thu, 20 Apr 2006, Pascal Bleser wrote:
> 
> [...]
> 
>>>> YaST2 should also get a decent way to update existing packages. This 
>>>> is currently (as of 10.0) a real pain to do, there's no obvious 
>>>> option. You have to select "package categories", go to "zzz all", 
>>>> right click on the right pane, "this list..." -> "update if newer 
>>>> version available". It's too complex, there should be a single icon 
>>>> in the YaST2 menu to do that operation in a dedicated way, since 
>>>> it's what almost every SUSE Linux user is doing, every single day 
>>>> for many of them.. well, at least those who use 3rd party 
>>>> repositories like mine, Packman, etc...
>>> Offering an update repository (in repomd style + patch infos) should 
>>> pretty straightforward on 10.1...
>> Great! Where can I find the documentation about it ?
>> - how to generate such repositories, where does the additional data come 
>>   from ?
>> - what are the repomd extensions ? schema or DTD ?
> 
> I'm afraid to have to tell you, that there isn't much documentation on a 
> technical level yet :( You'd have to dig into some YaST / libzypp / zmd 
> packages, to find the answers to your questions. But as we move along, we 
> will hopefully be able to deliver documentation on this in the future.

Keep in mind that as long as there isn't any documentation, it's more 
or less of no use outside of the SUSE team at Novell.

When you plan/implement such tasks inside the SUSE team, please 
consider spending a little bit of time on some decent documentation, a 
text file or a wiki page on opensuse.org is sufficient.
(AJ: hint, hint ;))

That's also an aspect of "community", keep in mind your stuff isn't 
just intended to be used by a handful of people who sit on the same 
floor, in the same building (near the "harddisk mortuary" 
(Maxtorgraben) in Nürnberg ;)).

>> Is it backwards compatible with plain repomd ?
> 
> It is, as it's just an extension to what repomd offers out-of-the-box. So 
> there are some more .xml files (one per patch) and the usual 
> primary/filelist/other .xml files.

Ah, ok, it's additional XML files. Great :)

> Check out http://download.suse.com/update/10.1/repodata/ for the details.

Allright.

What I can see there is
* Plain rpm-md files:
- filelists.xml.gz
- other.xml.gz
- primary.xml.gz
- repomd.xml ==> extended with

   
   ...
   1145376771
   ...


* Additional SUSE-specific files:
- patches.xml

   
     ...
     
   
...

- a lot of individual patch-*.xml files
(with a quite complex structure)

Well, everything seems pretty straightforward, except the patch-*.xml 
files.

I assume you've got some tooling to generate those, as well as a 
modified createrepo, right ?

How can we use those ?
- modified createrepo ? (that mentions ... 
in the generated repomd.xml, and generates the patches.xml file)
- tool to generate the patch-*.xml files ?

...
>> Which makes me think that... err... once y2pmsh will really be dead 
>> (i.e. non functional), y2pmbuild must be ported to something else. To 
>> smart ? Or is there some form of CLI driven package installation tool 
>> with libzypp ?
> 
> y2pmbuild should be fully functional with the BuildRequires expansion 
> stuff that went into build.rpm -- there is no real need to use y2pmsh, 
> IIUC.

Mmmmm.. not quite, as y2pmbuild uses y2pmsh to install missing 
BuildRequires into the build chroots.

cheers
-- 
   -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
   /\\        
  _\_v   FOSDEM 2006 -- 25+26 February 2006 in Brussels

Hi, On Thursday, April 20, 2006 at 17:14:54, Christoph Thiel wrote:

On Thu, 20 Apr 2006, Pascal Bleser wrote:

...

...

...

Which makes me think that... err... once y2pmsh will really be dead (i.e. non functional), y2pmbuild must be ported to something else. To smart ? Or is there some form of CLI driven package installation tool with libzypp ?

y2pmbuild should be fully functional with the BuildRequires expansion stuff that went into build.rpm -- there is no real need to use y2pmsh, IIUC.

Mmmmm.. not quite, as y2pmbuild uses y2pmsh to install missing BuildRequires into the build chroots.

Right, but that could be done by simple rpm calls + the BuildRequires expansion that comes with build.rpm! y2pmsh is only used to compute the dependencies, IIUC.

And for the repo handling. We just need uberbuild that incorporates all features of y2pmbuild, build.rpm and the build service commandline client. With the BuildRequires expansion we came a good step closer to a unified (local) build tool. The rest should be pretty straigth forward. Henne -- Henne Vogelsang, Core Services "Rules change. The Game remains the same." - Omar (The Wire)

Hi, On Thursday, April 20, 2006 at 20:36:55, jdd wrote:

Christoph Thiel wrote:

...

Frankly, this stuff has been developed within a very short timeframe under extrem pressure, so nobody cared about documenting this yet ;(

let me say that

* so may be we could help. I beg some of us (probably not me :-() can with quite little doc make a better document on the wiki and save you some hours...

don't hesitate to ask for help... and we can hold on till 10.1 final is out :-)

Quote from http://en.opensuse.org/Tasks Documentation * Document the new media handling and alternatives (autofs, ivman) in the SDB. * Document libzypp/zmd/rug on the Libzypp page. Libzypp contains some information, but rug is only documented by example, there's no wiki page for rug. zen-updater, zen-remover and zen-installer seem to be undocumented. If you are doing this coordinate in bug #163279 please. Ive just added * Document the rpm-md+ format we use in the 10.1 update directory. Please ask on the factory mailinglist if you have any questions about it. Henne -- Henne Vogelsang, Core Services "Rules change. The Game remains the same." - Omar (The Wire)

On Fri, 21 Apr 2006, Henne Vogelsang wrote:

Quote from

http://en.opensuse.org/Tasks

Documentation

* Document the new media handling and alternatives (autofs, ivman) in the SDB. * Document libzypp/zmd/rug on the Libzypp page. Libzypp contains some information, but rug is only documented by example, there's no wiki page for rug. zen-updater, zen-remover and zen-installer seem to be undocumented. If you are doing this coordinate in bug #163279 please.

Ive just added

* Document the rpm-md+ format we use in the 10.1 update directory. Please ask on the factory mailinglist if you have any questions about it.

Thanks -- at the moment this is still kind of a moving target ;( I'd actually want to avoid having someone reverse engineer the format now, because my hope is that we get some decent documentation on the format and its semantics, from the people that worked on this stuff. Regards Christoph

On Thursday 20 April 2006 12:46, Pascal Bleser wrote:

[...] And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".

newer -i ... but you almost always want to use "upgrade" anyways /me still dreams of pipes cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/

Hello, Am Donnerstag, 20. April 2006 15:42 schrieb Pascal Bleser:

Ludwig Nussel wrote:

...

On Thursday 20 April 2006 12:46, Pascal Bleser wrote: [y2mpsh stuff] newer -i ... but you almost always want to use "upgrade" anyways /me still dreams of pipes

Ew, nice one. Documented somewhere ? ;) (yes, I could have checked the source code)

;-)

And upgrade, well, yeah, but it always reinstalls the kernel package.

"system updade/upgrade (?)" YaST module downgrading the kernel was a bug in 9.3 and 10.0 and was finally fixed some time after 10.0 release - so it should work fine in 10.1 ;-) I guess this fix also fixes the y2pmsh behaviour - it uses the same codebase AFAIK. Regards, Christian Boltz -- Wieviele Leute braucht es, um Windows zu installieren? - Sieben! Einen, der sich die CD leisten kann, drei die ausdiskutieren, wie man das wohl macht, zwei Priester, die beten, dass es funktioniert und einen Psychiater, der die Nervenzusammenbrüche behandelt!!!