-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eberhard Moenkeberg wrote:
On Sun, 18 Sep 2005, houghi wrote:
On Sun, Sep 18, 2005 at 09:40:01PM +0200, Eberhard Moenkeberg wrote:
Together with Richard, I have organized such a "place for unsupported SUSE stuff" a long time ago (was at 7.3 times I guess) at ftp.gwdg.de - the APT repositories for SUSE.
Indeed. We 3rd party package maintainers owe Eberhard and Richard a big one there ;)
I Use SUSE for some years now and I never knew that. Really ? Oh.. well... shows that there's still a lot of work to do and focus to put into advocating and integrating 3rd party package repositories ;)
Ok, initially it was a creation for the apt4suse community. But meanwhile, we have many "YaST sources". ...
I first will look into making RPM's according the rules, becauise now I just run checkinstall and be done with it. Works great for me, personally.
checkinstall is nice to track a package you're only using on your own box, but is definately not a way to build packages to send out into the wild.
So I guess the time will come soon for suser-houghi. ;-))
Every "suser" ("suse user", Richard's creation) is encouraged to run createreo over his personal RPM directory at home. You could make it a requirement. I mean I running `createrepo /usr/src/packages/RPMS/` is not THAT difficult. It already IS a requirement in my head, but I am a shepard. ;-))
Not necessarely. I provide apt, yast2 and redcarpet. No need to do createrepo ;) (yast2 with my own scripts around create_package_descr, and redcarpet with opencarpet) It's great to have YaST2 being able to use createrepo metadata, but that only counts for >= 10.0, and I intent to provide packages for 9.3, 9.2, 9.1, 9.0 for a while (well, at least 9.3 and 9.2). So unless Novell is willing to backport that to yast2 on those distributions, I'm still stuck ;)
This gives the community the chance to directly add the suser-XXX repository as a YaST source. The disadvatage is that you have to add many repositories. Also many repos will have double RPM's in them with the chance of people doing work twice.
Exactly.
It is pretty well "coordinated" because most susers are communicating with and obeying their companions.
Unfortunately, that's not the case at all. We are some packagers to actually talk to each other (packman, me, tux, oc2pus) but I really don't know about the others. One of the first things we should put into place for that is a central mailing-list for all the 3rd party packagers, to at least try to coordinate what we provide and avoid double entries. There are still a lot of them, and there's barely any communication going on. Unfortunately, especially the suse-people don't talk to us non-suse-people. Some RPMs suddenly pop up into SUSE's "extra" repositories (kde, gnome) although they have been provided by others already (e.g. my k3b and amarok packages). Well, nice, I could just remove mine, but they're not always actively maintained. So, speaking for myself, I'm willing to remove packages from my repository if they're being maintained by others (especially SUSE extra repositories), but only if I'm sure they're also being maintained properly and updated as soon as a new release is available. Another issue is cross-referencing. I always make sure that I don't require a package that's not in my own repository (or part of the core distribution, of course), and I know that at Packman we have the same policy. But if everyone does the same, we'll always end up with multiple copies of libraries that are not provided within SUSE itself (e.g. ffmpeg). Those are the kinds of things that need to be addressed in the next weeks, to provide a much better user experience and avoid conflicts, multiple (often incompatible) copies of packages, etc...
Once the OpenSUSE build hosts are installed, all "susers" will get invited to move the RPM build process to the SUSE provided build hosts, and then all the "suser" repositories can move "one level higher", to be distributed centrally to all the SUSE mirrors.
Unless you have some information I don't (although I've been talking with cthiel, henne and darix about it the last weeks ;)), we're still not there. Yes, Novell will provide build servers, but what's happening beyond that is still void. We don't even know yet what those build servers will "look like".
Great. So what time will this be done? ;-) Lets say: probably not this year. But work is already in progress at SUSE, as Christoph has reported.
Indeed. But there's still a lot of work to do on how to aggregate, integrate, communicate, provide, ...
But again: you don't have to wait. First step is already here (at ftp.gwdg.de). Drop me a line to participate. Thanks. I will keep it in the back of my mind. At this moment my knowledge of building RPM's is limited to checkinstall. As I said, I will first learn some RPM building basics.Next wait what things I miss in 10.0 and then look if I could be of any use.
- - for the basics: Maximum RPM: http://www.rpm.org/max-rpm/
- - SUSE package conventions:
http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.htm...
- - read a lot of spec files :)
Note that for spec files to look at, I'd recommend using e.g. mine or packman's.
Not necessarely those from SUSE they're.. well.. let's say "they work" but aren't necessarely always
following the rules (e.g. not using RPM macros).
Maybe you'd want to read an RPM presentation I did some time ago at a LUG in Antwerpen:
http://linux01.gwdg.de/~pbleser/files/presentations/rpm-packaging.pdf
Those are only the slides but they're quite verbose (98 slides). It's in 2 parts: RPM for users
(boring), and RPM for packagers (that's where the real meat is at ;)).
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\