-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 houghi wrote: > On Mon, Oct 10, 2005 at 09:08:06PM +0200, Pascal Bleser wrote: >> Although SUSE Linux ships a huge number of packages, there is still a >> lot of stuff that's not included. > > I agree. However in the past if you bought SUSE there was already so much > in it that that starting to make your own was not really worth it, Perhaps
If I had thought that, there wouldn't be my repository today ;) > another reason was that the chance of getting officuially into the SUSE > distro wre prestty slim. Also for a lot of people, using the Mandiva or It was near nought, indeed. > RedHat rpm's (or other RPM's) just worked out of the box. Why would > somebody start making an rpm package for each and every distro around. Because that's just not true at all. Most Redhat/Fedora/Mandriva/whatever RPMs won't work on SUSE Linux, because each distribution has its own idiosyncrasies about where to install certain files (*), the names of the libraries (dependencies) (**), the available versions of libraries (dependencies) (***), how to configure and run daemons (****), etc... (*) e.g. KDE and GNOME: /opt/kde3, /opt/gnome for SUSE, /usr for Fedora/RH (**) e.g. kdelibs3 on SUSE, kdelibs on Fedora (***) e.g. GNOME 2.10 on FCx, GNOME 2.4 on SUSE (****) different init scripts, sysconfig files on SUSE For the simplest of packages, it might work (e.g. sed or awk) but for others, it definately won't work properly. At best, the file locations are plain wrong but it kinda works anyway, at worse, you can't even install the package because the dependencies are totally different. > If I made a SUSE rpm, it won't be available for Mandrake, RedHat, Debian, > ... Yes. And ? That's the whole point of making RPMs for SUSE Linux. Same goes for the others: if you do a Debian package, it won't be available for Mandriva, Redhat, Fedora, SUSE. If you do a Mandriva package, it won't be available for Redhat, Debian, SUSE. What's your point here ? :) Unfortunately, that's the situation. The RPMs are bound to the distribution. Even worse, binary RPMs are actually bound to a given version of a distribution, because of dependencies, shared libraries the binaries have been linked against, etc... That's not going to change anytime soon, we have to live with it. The only level of compatibility we could achieve would be on the source packages, or rather the .spec files, but it requires packagers from every distribution to add their bits in there. We'll probably never have .spec files that work on any RPM-based distribution out-of-the-box. The only thing we can do is "single source", and put what's needed and what's different with every supported distribution. Been there, tried that, it's almost hopeless. >> And I really think that the core >> distro should shrink a little (or at least stop growing) because at some >> point, quantity would get over quality, and that's definately not what >> any of us want. It's up to the openSUSE community to grow more packagers. > > Stop growing, because people expect SUSE to be humongous. It is as if SUSE > as a distro goes to eleven with the number of included packages. Stop growing ? Are you kidding me ? In numbers of packagers, we're near 0, we *must* have more committed packagers in the community. Having around 30 dedicated people is a minimum. You're really expecting the dozen of people (at most) in the community actively making RPMs for SUSE Linux to keep on going like this forever ? Believe me, currently it's really not a motivating situation. At least it isn't for me. I definately want to reduce the number of packages I maintain, by a large margin. And being a good packager takes time, there's a lot of know-how behind it. If I stop packaging because I don't have the time for it any more, you loose 500 packages. If two other people at packman do the same, you'll loose another 500-1000 packages. What then ? This cannot be the situation to live with. With "growing packagers" I mean that those few people doing it now should pick up 2 or 3 really motivated volunteers and coach them, help, review their spec files, etc... That would be a good start. Or join Packman, where we already have a slightly larger team (around 7-8 active packagers) and especially where we have an infrastructure. >> To me, that's the #1 priority for openSUSE (as a community), but I guess >> everyone sees other #1 priorities ;)) >> (and that's good, it not only shows there's still work to do to leverage >> our community (at least in numbers) but also that we actually have ideas >> on how to do that) > > I really, really, really would love to see a lot of maintainers for one > huge repo, which everybody (after some quilification) can link they YaST > to, to get anything they like. That way it can already be added at > instalation. We already had some discussion about it, I'm sure you've seen the threads some 2-3 weeks ago. Note that we almost have "one huge repo", and that's Packman. I'll be merging my packages with them and join the crew, which will mean Packman will host about 80-90% of the SUSE RPMs made by the community. Which also means it pretty much becomes a single point of failure. Having it added at installation time isn't really necessary. What would be badly needed is that YaST2 regularely pulls a list of community repositories from, say, some location on opensuse.org and offers that as a checklist to the user, along with a description of the repository, a list of available mirrors (we do have some for Packman), and a disclaimer that Novell isn't liable for the packages in there, etc... There's still an issue with the mp3 and mplayer stuff though. Given the laws in the US, Novell isn't even allowed to point to such repositories. Those will always have to be added "manually". [...] cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDS0tNr3NMWliFcXcRArVeAJ4nV9UfjiZKnmJraKqdfWLxPGkx8QCfY+53 u09pkexxTXFh/UF2wmJFg28= =uBhN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
