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