-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Thiel wrote:
On Mon, 19 Jun 2006, Martin Schlander wrote:
Torsdag 15 juni 2006 13:47 skrev Christoph Thiel:
On Thu, 15 Jun 2006, Pascal Bleser wrote: Maybe the two of you should cooporate instead of "competing"? :)
We are not really competing -- we are booth driving smart adoption. The biggest challenge in collaboration is the fact that Pascal offers some .channel files, that we at Novell can't ship for different reasons.
Right. Another point is that the BS repos don't have much visibility as of now, at least not as much as mine. Well, we'll see what the best option is. Maybe working together on only one smart package would be better, and just provide a link to a big .channel file with the repos that may not be shipped within a smart package hosted on the BS... Although, frankly, I get a lot of mails and feedback of people who really appreciate that they just had to install the one smart package from my repo and everything was set up properly. I'm not sure I'd want to break this or make it more complicated for end-users.
Just read that Pascal calls for testing of his patched Smart packages on 64bit systems.
Yes please :)
I'm already testing Christoph's packages here on my 64bit system. Not a glitch so far btw. I'm a bit confused with Pascals patches though - will those have any affect for gui users?
I haven't really looked at Pascals patch, but might merge it into the SUSE smart package, once I looked at it and once we have some feedback on it upstream.
The patch is described here: http://tracker.labix.org/issue177 It's experimental, it really is, so I'd say better don't include it in the BS smart package as of now. I'm waiting for some feedback to see whether it works for others than me (or not). Nothing yet so far :\
I have 32bit Mplayer installed though 64bit is available - but it seems to have problems with certain codecs. So I mostly use 64bit Kaffeine/Xine and supplement with 32bit Mplayer when needed. Will Pascals patches cause problems with this?
Hopefully not.
Right, I sure hope not ;) Well, it will cause a "problem", somehow, because when you say $ smart install MPlayer it will install the x86_64 MPlayer RPM, not the 32bit one. You'd have to explicitly say $ smart install MPlayer-1.0....@i586 to install the 32bit one. But I think that should be the case with a pristine smart as well. My patch just changes the behavior of smart when you have a package that's - - both available as 32bit and 64bit - - the 32bit is newer (higher version number and/or release) Pristine smart would install the 32bit package because it has a higher version and/or release number. With my patch, it will install the (older) 64bit package, because it's a 64bit package on a 64bit system ;) A 32bit package will only be installed if there is no 64bit package available - unless, of course, you explicitly run something like $ smart install foo-...@i586 Basically, when you run $ smart install foo smart computes a list of candidate packages to install. That's a sorted list of RPMs (the 1st one from the list being chosen), and an unpatched smart will sort on the version and release number first, while with my patch, it will favor a x86_64 package (on a x86_64 system) first, and then only compare versions. Note that if you already have, e.g., MozillaFirefox installed as 32bit and run $ smart upgrade MozillaFirefox it will upgrade with the 32bit package, not the 64bit one (which is what you'd want). That behavior is already in pristine smart, I didn't change anything there, but just to mention it still works the same way with my patch applied.
Anyway, it's great that development is being done on Smart - and that we get a chance to try things out early with easy installation of packages from repos. But it's getting a bit confusing for us users (or at least me) which version has which patches etc. Any chance you could coordinate? Or is Pascal working on a fork? :)
I'm not working on a fork. I've been including a lot of patches, a good part of them having been written by me, but all those patches have been merged upstream (and, hence, are also included in Christoph's smart package), so basically, they're the same, with the exception of: - - the ability to embed mirrors into .channel files (hasn't been merged upstream yet) - - that "better priority handling" for 64bit, but that patch is only in my experimental smart repo, not in the smart package that's available from my main repository
Pascal will tell you that he can't split of a smart-channels package, to carry the stuff that we can't ship, because his users are used to get the channels preconfigured and it would obviously be confusing to them to change this. Otherwise it would be quite easy to offer only one smart package for SUSE Linux via the Build Service (and of course in the distribution).
Exactly. As I wrote above, a lot of people actually like the fact that
they get all those channels preconfigured.
Putting them into a "smart-channels" package means that users would have to:
- - install smart from the BS
- - add a repository that contains the smart-channels package
- - install the smart-channels package
Currently, with my "all-in-one" smart package, the procedure is as follows:
http://dev-loki.blogspot.com/2006/05/how-to-install-and-use-smart-on-suse.ht...
OTOH, having Christoph, Mauricio and I maintain a single smart package
in the BS is of course very compelling.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\