Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [opensuse] bug fix support by community
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Thu, 20 Apr 2006 12:46:23 +0200
  • Message-id: <4447667F.8010004@xxxxxxxxx>
jdd wrote:
houghi 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

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.

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.

The current YOU update checker should be refactored to fetch the metadata of all the "installation sources" that have been registered into YaST2 (e.g. like how ksmarttray does) and notify the end-user when new packages are available.
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 with 10.0's SUSE watcher, a click on the icon could trigger a specific YaST2 mode that shows a list of new packages and updates to existing packages (something similar to what YOU does).

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...

I currently have around 400 active projects that I package, part of them are not shipped with SUSE Linux at all, and the other part are newer versions (e.g. gimp, gaim, amarok, blender, lyx, ...).

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.

Spend a few evenings on IRC (, #suse) or on web forums and have a look at what end-users are asking, where they need help, and you'll notice quite quickly what operations are too tedious, too complex and would require some refinement in YaST2.
I very often recommend to install smart first, as it allows to do many package management operations in a much more straightforward way, without asking the end-user to manually resolve a dozen "conflicts".
As an example, the always recurring MP3 support question is answered by:
- install smart (from suser-guru)
- smart comes preconfigured with suser-guru and packman channels, so fortunately there's no need to add those repositories
- smart install libxine1 amarok amarok-xine

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)
- make sure they're on autorefresh
- add an installation source for SUSE Linux 10.0 (as the CDs or DVD don't include all the packages) - something you don't have to do with smart either, as it comes preconfigured with that
- open YaST2's "software management" screen
- select "Search"
- search for "libxine1"
- check the box for libxine1
- search for "amarok"
- ("oh, it's locked and/or red..hmm.. why is that ?" - "no idea, don't bother")
- click on amarok and amarok-xine until it shows the update icon
- press OK

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, ...)

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.

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

Yes, partly.
But if you want to submit bugfixes to e.g. YaST2, you should pull the YaST2 source code, make patches and submit them to the YaST2 maintainers (either through bugzilla or by mail).

Of course all this won't happen right now

Indeed. And I doubt it will happen any time soon.

-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels

< Previous Next >