-----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/
/\\