Just a thought that had been going through my head over the weekend... At the moment on OpenSUSE.org, we provide a link on the Download page to the information on external YaST repositories, and there has been talk of making some of them available in YaST as an option in future versions.[1] Thing is that that's for sw_single and the same doesn't also apply for online_update - it can only have one source of packages at a time, and to say to users: "Sometimes you will want to run the Online Update option in YaST to get the latest updates, but sometimes you'll want to run the Software Management option is little counter-intuitive.[2] I would like to suggest it be consolidated into a single component that handles adding and removing packages, as well as updating from all YaST sources, and SUSE update trees. That's all I'm going to say about it now, any thoughts? In fact, is anyone else on this list? ;) [1] Note that those external repositories need to be set to refresh on YaST startup. [2] This has come out of the fact that I'm going to be setting up "OSS" for some friends, and I've gone through exactly this thought process before giving them the CDs. -- James Ogley james@usr-local-bin.org Packages for SUSE: http://usr-local-bin.org/rpms Make Poverty History: http://makepovertyhistory.org
James Ogley
Just a thought that had been going through my head over the weekend...
At the moment on OpenSUSE.org, we provide a link on the Download page to the information on external YaST repositories, and there has been talk of making some of them available in YaST as an option in future versions.[1]
Thing is that that's for sw_single and the same doesn't also apply for online_update - it can only have one source of packages at a time, and to say to users: "Sometimes you will want to run the Online Update option in YaST to get the latest updates, but sometimes you'll want to run the Software Management option is little counter-intuitive.[2]
I would like to suggest it be consolidated into a single component that handles adding and removing packages, as well as updating from all YaST sources, and SUSE update trees. That's all I'm going to say about it now, any thoughts? In fact, is anyone else on this list? ;)
I'm on the list ;-) Yes, a long needed change. If you install a new package, you do not want to install the old version from the repository or media and then have to run a YOU update to get the fixes in... Hope we can get this implemented soon - we have already folks evaluating this. Thanks for the suggestion, Andreas
[1] Note that those external repositories need to be set to refresh on YaST startup. [2] This has come out of the fact that I'm going to be setting up "OSS" for some friends, and I've gone through exactly this thought process before giving them the CDs.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Ogley wrote:
Just a thought that had been going through my head over the weekend...
Funny, I had some thoughts about the same thing recently ;)
At the moment on OpenSUSE.org, we provide a link on the Download page to the information on external YaST repositories, and there has been talk of making some of them available in YaST as an option in future versions.[1] [1] Note that those external repositories need to be set to refresh on YaST startup.
Yes, I think that's badly needed. As I already posted in some of my mails on the main list, it seems that our 3rd party repositories are too difficult to find and to install. Even on the main list, a few users said they didn't know about our repositories although they were using SUSE Linux for some time. A similar system to what YOU does would be nice, IMHO: - - refresh the list of available repositories at startup, from a central location, e.g. opensuse.org - - have some simple metadata format for the repositories, e.g. including a description of the kind of packages to expect in that repository (bleeding-edge gnome, multimedia, anything..) - - have a simple dialog for the end-user to add or remove those repositories (a check list, basically), and as you said: they must be added with auto-refresh turned on Of course, add a big fat disclaimer that Novell is not responsible nor liable for the content of those repositories, they might break your system, they're not tested by Novell, that they might install packages you're not allowed to depending on the laws in your countries, yadda yadda, IANAL ;)
Thing is that that's for sw_single and the same doesn't also apply for online_update - it can only have one source of packages at a time, and to say to users: "Sometimes you will want to run the Online Update option in YaST to get the latest updates, but sometimes you'll want to run the Software Management option is little counter-intuitive.[2] I would like to suggest it be consolidated into a single component that handles adding and removing packages, as well as updating from all YaST sources, and SUSE update trees. That's all I'm going to say about it now, any thoughts?
I second that. Actually I would propose to re-think the current concept of YaST2's Software Management module. To me, it should be an aggregator of package information from various sources: - - SUSE repositories - - supplemental, if checked - - 3rd party repositories, if checked - - Online Update (or not, if it is obsoleted by YaST2 Software Management) I'd also suggest to define some metadata format to "mechanize" that information, and all the 3rd party packagers would have to provide such metadata to be integrated into the "YaST2 Software Central" (or whatever). XML seems well-suited for that purpose (also because it can be directly transformed to, say, HTML). That metadata could include things like: - - package name, package version, release (obviously) - - release scope: new features, bugfix, security fix - - version state: beta, stable - - changelog information - - description - - link to project website - - screenshot(s) Screenshot(s) may sound futile, but... how about providing some kde-apps.org-like interface ? See for yourself: http://kde-apps.org (but I guess everyone on this list knows that site already ;)) Actually that's kde-apps.org and freshmeat.net alike. Note that e.g. the freshmeat.net project metadata (XML) can already be used for most of the stuff above. I do so already, but only for part of the information (see my previous post on the list about my little script and emacs macro that fetches that data). Obviously, and that's probably the reason why this will never happen, implement all of this requires a major YaST2 overhaul, especially as far as the Software Management module is concerned :\
In fact, is anyone else on this list? ;) Yep ;)
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Monday 03 October 2005 11:48, Pascal Bleser wrote:
James Ogley wrote:
Thing is that that's for sw_single and the same doesn't also apply for online_update - it can only have one source of packages at a time, and to say to users: "Sometimes you will want to run the Online Update option in YaST to get the latest updates, but sometimes you'll want to run the Software Management option is little counter-intuitive.[2] I would like to suggest it be consolidated into a single component that handles adding and removing packages, as well as updating from all YaST sources, and SUSE update trees. That's all I'm going to say about it now, any thoughts?
I second that. Actually I would propose to re-think the current concept of YaST2's Software Management module. To me, it should be an aggregator of package information from various sources: - SUSE repositories - supplemental, if checked - 3rd party repositories, if checked - Online Update (or not, if it is obsoleted by YaST2 Software Management)
jfyi, we do think about such a tool, but it will not happen within the next 6 month from the SUSE side. Maybe we could create some temporary solution, simply using a small application around the http://kstuff.org/ mechanism. A client would be provided already via the kdelibs, we only need to figure out how to setup such a server (but I have some contacts how can answer this ;)
I'd also suggest to define some metadata format to "mechanize" that information, and all the 3rd party packagers would have to provide such metadata to be integrated into the "YaST2 Software Central" (or whatever). XML seems well-suited for that purpose (also because it can be directly transformed to, say, HTML).
That metadata could include things like: - package name, package version, release (obviously) - release scope: new features, bugfix, security fix - version state: beta, stable - changelog information - description - link to project website - screenshot(s)
Screenshot(s) may sound futile, but... how about providing some kde-apps.org-like interface ? See for yourself: http://kde-apps.org (but I guess everyone on this list knows that site already ;)) Actually that's kde-apps.org and freshmeat.net alike.
Note that e.g. the freshmeat.net project metadata (XML) can already be used for most of the stuff above. I do so already, but only for part of the information (see my previous post on the list about my little script and emacs macro that fetches that data).
Obviously, and that's probably the reason why this will never happen, implement all of this requires a major YaST2 overhaul, especially as far as the Software Management module is concerned :\
yes, but this will happen anyway ;)
In fact, is anyone else on this list? ;)
Yep ;)
m2 bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Schroeter wrote:
On Monday 03 October 2005 11:48, Pascal Bleser wrote:
James Ogley wrote: ... Actually I would propose to re-think the current concept of YaST2's Software Management module. To me, it should be an aggregator of package information from various sources: - SUSE repositories - supplemental, if checked - 3rd party repositories, if checked - Online Update (or not, if it is obsoleted by YaST2 Software Management)
Hi Adrian ;) Great to have you on this list.
jfyi, we do think about such a tool, but it will not happen within the next 6 month from the SUSE side.
Ok. Yes, I can imagine the YaST2 developers are a bit reluctant to change the Software Manager component ;)
Maybe we could create some temporary solution, simply using a small application around the http://kstuff.org/ mechanism. A client would be provided already via the kdelibs, we only need to figure out how to setup such a server (but I have some contacts how can answer this ;)
Basically, a <knewstuff/> feed at every packager's site. At the very least we can do that at Packman and my site (or, well, the merged one). <knewstuff/> items can then get piped into to "yast2 -i". But there are two issues: 1) dependencies: if yast2 hasn't been properly set up in terms of 3rd party package repositories, the "yast2 -i" is likely to fail on missing dependencies (*) 2) aggregation: maybe I should get into more detail about knewstuff but I suppose that having a single, aggregated feed of package updates would be much better than having one per repository (**) (*) well, ok, we loose some user-friendliness there, but we could temporarely work around that with documentation and installation notes or similar (**) maybe opensuse.org can play a role here, but we discussed already about legal issues, e.g. a feed on/from opensuse.org giving a link on lame, mad, win32codecs-all, mplayer, etc.. that's on Packman (or elsewhere) - From a technical point of view, I think the <knewstuff/> feed representation format is a big pain, because RDF and Atom perfectly fit their needs but hey... ;)
I'd also suggest to define some metadata format to "mechanize" that information, and all the 3rd party packagers would have to provide such metadata to be integrated into the "YaST2 Software Central" (or whatever). XML seems well-suited for that purpose (also because it can be directly transformed to, say, HTML). That metadata could include things like: - package name, package version, release (obviously) - release scope: new features, bugfix, security fix - version state: beta, stable - changelog information - description - link to project website - screenshot(s)
Some of that is included in the <knewstuff/> format: http://www.kstuff.org/docs/tutorial/ (see the "Server side: File formats" section) ...
Obviously, and that's probably the reason why this will never happen, implement all of this requires a major YaST2 overhaul, especially as far as the Software Management module is concerned :\
yes, but this will happen anyway ;)
Great to hear so :)
So, based on knewstuff, a first prototype version seems pretty feasible.
I think the problematic part is the server-side, because the format includes voting, number of
downloads and similar, that has to be actively processed by the server-side, so it's not just a
"read only" thing as it would with RSS/RDF/Atom.
That's an issue indeed, as not everyone (packagers) around here could have such a server-side
application running, to update their database. At least those hosted on gwdg.de can't.
At Packman we could implement that. As we're currently finishing the overhaul of the Packman
website, I could try to implement a prototype (on the server-side).
That could be a first step. Then add the client. Any KDE wiz around here ? ;)
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
participants (4)
-
Adrian Schroeter -
Andreas Jaeger -
James Ogley -
Pascal Bleser