Christoph Thiel wrote:
On Mon, 29 May 2006, Pascal Bleser wrote:
2) I preconfigure my smart package with a lot of channel files, including packman and guru so... legal issues ? Indeed -- but I'd rather split those channel files into a new package and have smart depend on it (or suggest it). I might even be able to put a channel package into SUSE Linux, with a reduced set of channels. Mmmmmyeah, that would be a technical option, but not a good thing for end-users IMO. When I look at the current situation with 10.1 and its broken zypp, end-users are already struggling to install my smart RPM (mostly because it depends on rpm-python, that is not installed by default) and have to jump a few hoops because YaST2 or rug just won't work on their system: http://dev-loki.blogspot.com/2006/05/how-to-install-and-use-smart-on-suse.ht... http://spinink.net/2006/05/20/installing-smart-package-manager/
So adding another package/dependency would make things even more complex.
And from a technical POV, if I put those channels into, say, smart-suse-channels.rpm, you can't really make smart.rpm depend on it because smart-suse-channels.rpm won't be in the Build Service.
So, why would users want to install your smart package, instead of going for the one that's already in the distribution? Only because of the preconfigured channels?
Two reasons: - preconfigured channels 99% of people want to use anyway - up-to-date builds Granted, at the moment there isn't much development happening with smart, but that will change soon as Gustavo (Niemeyer, the smart maintainer) will get dedicated time to work on it from Canonical (at least it's very likely, he told me so last week). Now, if the Build Service is easily accessible by end-users and establishes itself as an *easy* package installation channel for them (like Packman or my site), it's a different story. They wouldn't further be dependent on the version that's shipped with a SUSE Linux release, but could update directly to the latest build that would be maintained in the BS. Nevertheless, preconfigured channels is a major feature. Not to me, not to you, nor to most experienced users, as adding channels or especially just adding some .channel files is pretty trivial with smart, but it does to less experienced end-users. The feedback has really been great on IRC, everyone is very happily using it. It lacks a few features (when compared to apt-rpm or y2pmsh) and has some the latter don't, but it works, it's stable and I only got very few bug reports that I could fix very quickly (see the batch of patches I've submitted upstream, it's the original mail that's not in this thread.. well.. not on this list ;D). Just to say that those preconfigured channels are part of its acceptance: just install my smart RPM (and rpm-python), "smart update" and it works, including for packman and guru, which almost everyone asks for anyway (for mp3, video codecs, latest amarok, latest gimp, etc...) as well as supplementary KDE, latest wine packages (build by Marcus Meissner), latest mozilla.org packages. Note that those 3 are disabled by default, but can be enabled very easily: smart channel --enable suse-kde smart channel --enable suse-mozilla smart channel --enable suse-wine And it includes 4 or 5 mirrors for every channel too, out of the box.
Installing the SUSE smart package (+requirements), after doing a default CD / DVD or network installation, should be working without any problems, even with libzypp.
Unfortunately it doesn't :\ Usually people come asking for a solution when they're stuck with a non-working zypp (doesn't install anything, crashes, takes huge amounts of resources, etc...), which is when we (on IRC) tell them to use smart instead, at least until zypp is fixed.
To solve the channel Problem, we should look into registering a mime-type for .channel (or .repo) files, to handle them with a helper script when $users tries to access them.
Right, that would be very neat.
I don't want to discard or discredit your efforts on the BuildService, but I really don't see any advantage for me in using it at the moment, it's rather the opposite: - I build for SUSE 9.1 -> 10.1, and only 10.0, 10.1 and Factory are in the BS as of now (AFAIK)
9.3 has been added recently. [9.1 has just been official discontinued and Adrian is telling me, that 9.2 won't be added to the Build Serivce, right?) CORE9 (SLES9 / NLD9) might be an interesting target in the future.]
Mmmm.. OK, I guess I'm going to drop 9.1 builds as well then. Don't know about 9.2, I think it's not being used a lot any more. From the feedback I get, it's usually either 9.1 or 9.3. And yes, CORE9 and CORE10 would be nice :) I regularly get requests for building my packages (at least some of them) on SLED9 or SLES9, but I can't do that ... or rather I'm not willing to do that if I have to pay for a license.
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
+1 ;)
(and IMO, as a feature, ppc > CORE9/CORE10 ;))
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\