Christoph Thiel wrote:
On Mon, 29 May 2006, Pascal Bleser wrote:
2) I preconfigure my smart package with a lot of
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.
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:
So adding another package/dependency would make things even more
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 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
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.
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
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.
make the BS more compelling to me would be to have a ppc
build target (and providing what I'm missing, above ;)).
(and IMO, as a feature, ppc > CORE9/CORE10 ;))
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be>
_\_v http://www.fosdem.org http://opensuse.org