Saturday, September 10, 2005

» openSUSE contributed package aggregator

One of the major issues with contributed packages for SUSE Linux seems to have been that they are difficult to find, and that only part of the SUSE users are actually aware of Packman, my repository and the others. The other, in my opinion, is that we packagers don't communicate much and we sometimes end up with having the same package in several repositories, sometimes even conflicting and incompatible (e.g. because of the naming). I have some of those myself ;) To address the first problem, there are a couple of solutions that could work: » centralize all the contributed packages inside a same infrastructure, e.g. the openSUSE site » augment YaST2's package management module to have it fetch a list of contributor package repositories from a central location (opensuse.org would be my first guess) on the internet and propose to easily add some (or all) of them to the list of installation sources used by YaST2 » keep decentralized package repositories but aggregate them in some way on the openSUSE.org website A centralized site for all the packages is not feasible, as already shortly explained on the openSUSE mailing-list by Christoph Thiel, Robert Schiele and Christoph again. The 2nd and 3rd points share the same idea of keeping decentralized package repositories (more or less like now, although we need a lot more collaboration and communication to avoid incompatibilities, projects packaged several times, etc...) but aggregating them in some way, be it on openSUSE.org. More ideas on that later, but maybe having a kde-apps.org-like web interface (maybe even inside YaST2 ?), as Marco Maske has proposed, is an option as far as user-friendlyness is concerned. Nevertheless, as package managers and advanced users, we also need tools to see whether a piece of software is already packaged, where, in what version, in what state, see what packages are unmaintained, provide them on all supported architectures, etc...

4 Comments:

Blogger Mark said...

I say we should just make a massive repository on the SUSE linux site and its mirrors and let people submit their packages to there. Maybe they could also submit just links to their own repositories.

But regardless of how it is setup, I think it somehow needs to be very easy for some random person to install additional packages, even for exotic software.

Mark

16:03  
Blogger Werner said...

The goal should really be one central yast-source for all suse packages that is fed by individual packagers like Pascal and the packman guys.

Just a users point of view

16:12  
Blogger zekus said...

why not use an open-carpet solution with a dedicated channel?

01:45  
Anonymous Wildhair said...

This is a concept I have thought long and hard about not only for Linux but Windows being a packager for that system.

I see a site that would hold databases with the base information on a number of distros that could then be queried for basic information such as versioning, file paths, ect.

Then another database for each distro that could contain the application information for each distro. Although the filebase seems to help there are still conflicts that arise from one person bundling one library version vs the stock version or conversely, not bundling in a library because something else put it on their system and they assume that it is not needed for their app.

I'd also like to see a more standard approach to software installs. You have Apt, RPM, Gentoos approach and Tar files none of which are compatible with each other. I like Gentoos slots approach to app compatibility which does not exist for RPMs. I have not used APT were I am familiar with its paridgm for installs.

It is going to require a group of sorts going out and defining guidelines and then outline it before you can even start talking to people about creating a standard across the Linux distribution platforms. Then it would be simple enough for the vendors to write something to work within those guidelines. Somewhat like MS has done with the MSI format and the msiexec.exe engine. Evem this is not perfect because you have someone like myself who deals with MSI formats all day and a vendor who may do it twice a year and makes a few things non-standard that I have to fix in order to get it to work properly in an WAN/LAN environment with thousands of computers.

At least that is how I see it. Dunno about the remainder of you.

Regards....

21:04  

Post a Comment

Links to this post:

Create a Link

<< Home