Adrian Schröter wrote:

Am Wednesday 31 May 2006 01:49 schrieb Pascal Bleser:

...

Pascal Bleser wrote: ... (BTW, just to make it clear: those amarok RPMs have the same crippled proprietary codec support as usual - to get full-featured codec support, keep on using the packages from... you know where ;))

amarok is not crippled at all, because amarok does not contain any codecs at all. This amarok is really full featured.

Yes, sorry, that's mostly correct, although with one exception: ./configure \ --with-mp4v2 => MP4 support (through faad2) That switch is not enabled in the BS (KDE:Backports) amarok.spec for reasons we all know about ;)

You may speak about the xine package...

As well ;) cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v http://www.fosdem.org http://opensuse.org

Rainer Klier wrote:

Am Mittwoch, den 31.05.2006, 09:43 +0200 schrieb Adrian Schröter:

...

Am Wednesday 31 May 2006 01:49 schrieb Pascal Bleser:

...

Pascal Bleser wrote: ...

...

The KDE supplementary repository is now empty and has been moved to the Build Service: http://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/supplementary/KD E/README ...

...

There's also a backports repository, where popular KDE applications are built against the stock KDE version as shipped with 10.0 or 10.1, respectively. Just to clarify (and after reading the README again ;)): if you want the latest KDE + the latest KDE applications (e.g. amarok, koffice, ...), then you must add *both* repositories.

e.g. on SL 10.1: http://software.opensuse.org/download/repositories/KDE:/KDE3/SUSE_Linux_10. 1/ *AND* http://software.opensuse.org/download/repositories/KDE:/Backports/SUSE_Linu x_10.1/

and does ist work for suse 10.0 the same way (of course by using "SUSE_Linux_10.0" as the latest sub-directory)?

Yes: http://software.opensuse.org/download/repositories/KDE:/KDE3/SUSE_Linux_10.0... http://software.opensuse.org/download/repositories/KDE:/Backports/SUSE_Linux... (and the same for 9.3 as well)

i tried that. but yast said something like this: "no productinformation under this path. if you whould like to access a product, go back and enter the correct path. if you whould like to use the rpm-packages from this path go ahead."

what does that mean?

It means that YaST2 tried to add that repository as a yast2 format repository, but the Build Service only provides RPM-MD format repositories. I don't understand why that doesn't work with SL 10.0, as YaST2 in 10.0 also has support for RPM-MD. It should auto-detect the URL as being an RPM-MD repository. Note that it doesn't work for 9.3 - there you have to use e.g. smart

is that an error?

Yes.

will i have a problem?

No, you're just not able to add the repository. Please try as follows (as root, on a shell): installation_sources -a \ http://software.opensuse.org/download/repositories/KDE:/KDE3/SUSE_Linux_10.0... cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v http://www.fosdem.org http://opensuse.org

Am Wednesday 31 May 2006 11:27 schrieb Rainer Klier:

Am Mittwoch, den 31.05.2006, 09:43 +0200 schrieb Adrian Schröter:

...

Am Wednesday 31 May 2006 01:49 schrieb Pascal Bleser:

...

Pascal Bleser wrote: ...

...

The KDE supplementary repository is now empty and has been moved to the Build Service: http://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/supplementar y/KD E/README

...

...

There's also a backports repository, where popular KDE applications are built against the stock KDE version as shipped with 10.0 or 10.1, respectively.

Just to clarify (and after reading the README again ;)): if you want the latest KDE + the latest KDE applications (e.g. amarok, koffice, ...), then you must add *both* repositories.

e.g. on SL 10.1: http://software.opensuse.org/download/repositories/KDE:/KDE3/SUSE_Linux _10. 1/ *AND* http://software.opensuse.org/download/repositories/KDE:/Backports/SUSE_ Linu x_10.1/

and does ist work for suse 10.0 the same way (of course by using "SUSE_Linux_10.0" as the latest sub-directory)?

i tried that. but yast said something like this: "no productinformation under this path. if you whould like to access a product, go back and enter the correct path. if you whould like to use the rpm-packages from this path go ahead."

It is a generic warning of YaST in 10.0 that extra functionality (like selections or extra product informations) are not available with YUM repositories. This has been changed for 10.1 YaST will anyway see all rpms inside and you can use it as usual with the YaST software installation or the "system update" functionality. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de

onsdag 31 maj 2006 12:14 skrev Daniel Bauer:

It works in Yast, but I see KDE 3.5.3 - and on the KDE page "only" 3.5.2???

(I have seen this topic somewhere before but couldn't locate it again searching the list with google, so could somebody please give me the URL in the ML or shortly repeat to me why/how Suse is ahead of KDE?)

Just one of the many benefits of SUSE - happened with 3.5.0 too - which was also available for SUSE users ahead of time. I believe the reason is that major vendors get the source code early for making packages. And of course it probably doesn't hurt that a lot of KDE devs work at SUSE. I'm guessing 3.5.3 will be official in a matter of a couple of days. Martin Schlander

Eberhard Moenkeberg wrote:

...

I know Adrian has written 2 or 3 times that he wants to move suppl. KDE to the BS, but what you guys think is trivial and not important is actually being used by a vast number of SUSE Linux users out there. Some announcement, e.g. a week beforehand + published on the opensuse.org frontpage and feed, would have been desirable, to say the least ;)

The german word for such handicapped professionals is "Stuemper".

Na na na... ab ins Bett! The german word for such people is "zerstreuter Professor". Which roughly translates to "absent-minded professor", meaning people who are mostly unaware of the real world around them but still perform very well in the area they specialized in. Regards, Carl-Daniel -- http://www.hailfinger.org/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eberhard Moenkeberg wrote:

Hi,

On Wed, 31 May 2006, Pascal Bleser wrote:

...

In case you didn't notice (yet) and while an announcement of the maintainer(s) would have been nice ;)...

The KDE supplementary repository is now empty and has been moved to the Build Service: http://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/supplementary/KDE/R...

Seconded your protest & request for better transparency. This was really an is-no-good happening. The biggest ever. ... For APT the old directories are simply gone, and the new directories still are not configured, plus: it IS NOT TRANSPARENT ENOUGH FOR ME TO DO IT!

So: PROTEST against this unconcious behaviour!

Yes, it's a bit... unfortunate ;) As said, it's a good move to have it in the BS, but guys, please keep in mind what it can involve and all the side effects. Just to be clear: I'm not saying it shouldn't have been moved to the BS - - but it must be better advertised, announced, and coordinated with us (or at least some of us). Examples: - - Eberhard doesn't know about it, so he can't update the apt repos (if at all), same goes for Richard (Bos) - - I didn't know about it, so I couldn't provide a package upgrade for smart in time (as it includes the KDE suppl. channel) - - we could have contacted mirror admins beforehand - - there must be an announcement on the front page of opensuse.org + in the newsfeed of opensuse.org + on planetsuse.org - - active helpers on the mailing-lists and IRC channels would have been informed and could have helped people asking for it, the information could have been spread to other parts of the community, such as the web forums Really, guys, technically it's a good move but from an organizational point of view, it's a disaster. You must inform the community (at the very least, a post on opensuse@opensuse.org and we can take care of the rest) a week before so we can put everything into place to make it a smooth experience to everyone. Please remember it next time ;D

...

That's a very nice move, but I'd like to make a couple of remarks nevertheless: - - is there already feedback from FTP admins for mirrors ?

No. Surprise only.

Ugh. I'm going to contact the skynet admin tomorrow. Can someone take care of contacting others ?

...

A lot of people are using that repository to use the latest KDE, and there was a very decent mirror infrastructure available (e.g. skynet, belnet, several mirrors in Germany, ...), but we're starting at 0 at the moment :\

Yes. Totally zeroed-out by an unconscious administrative act.

...

- - please announce such stuff beforehand

Not enough; those "switch-movers" at SUSE have to learn other matters before they should get allowed to touch the switch: "vision" the situation at the remote sides.

Ok, s/announce/announce and discuss/g ;)

...

I know Adrian has written 2 or 3 times that he wants to move suppl. KDE to the BS, but what you guys think is trivial and not important is actually being used by a vast number of SUSE Linux users out there. Some announcement, e.g. a week beforehand + published on the opensuse.org frontpage and feed, would have been desirable, to say the least ;) ...

cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEfOEQr3NMWliFcXcRAij+AJ4qAWC5IB/rRXbi1+aOekm166I4rwCfZYSR zEFNdylsG5sz34K/dcruDWQ= =LsD0 -----END PGP SIGNATURE-----

On Wed, 2006-05-31 at 02:03 +0200, Eberhard Moenkeberg wrote:

Hi,

On Wed, 31 May 2006, Pascal Bleser wrote:

...

In case you didn't notice (yet) and while an announcement of the maintainer(s) would have been nice ;)...

(snip) Seconded your protest & request for better transparency. This was really an is-no-good happening. The biggest ever.

(snip)

For APT the old directories are simply gone, and the new directories still are not configured, plus: it IS NOT TRANSPARENT ENOUGH FOR ME TO DO IT!

So: PROTEST against this unconcious behaviour!

(snip)

...

A lot of people are using that repository to use the latest KDE, and there was a very decent mirror infrastructure available (e.g. skynet, belnet, several mirrors in Germany, ...), but we're starting at 0 at the moment :\

Yes. Totally zeroed-out by an unconscious administrative act.

...

- - please announce such stuff beforehand

Not enough; those "switch-movers" at SUSE have to learn other matters before they should get allowed to touch the switch: "vision" the situation at the remote sides.

...

I know Adrian has written 2 or 3 times that he wants to move suppl. KDE to the BS, but what you guys think is trivial and not important is actually being used by a vast number of SUSE Linux users out there. Some announcement, e.g. a week beforehand + published on the opensuse.org frontpage and feed, would have been desirable, to say the least ;)

The german word for such handicapped professionals is "Stuemper".

PROTEST!

Cheers -e

I must stand with Pascal and Eberhard on this one. A community is better served by thinking of others when making decisions that impact them...something that clearly wasn't done in this case. Just because one has the power to do something without permission doesn't mean appropriate advance communication shouldn't be part of the mix. Keith -- Keith Kastorff kastorff@yahoo.com

Am Wednesday 31 May 2006 05:41 schrieb Shriramana Sharma:

This is a really bad move. No FTP access, no development packages -- very bad publicity. :(

Hey, everything is still there, only at a different location and a README describes it.

I was a regular updater -- even when people used to recommend the "virgin" distro for stability, I used to download the latest KDE updates eagerly. And now that's no more possible, or at least not as easy as before. Some hacks will be needed before I can conveniently download the base and application packages... But I want my Qt 4!

You get even a newer Qt 4 at http://software.opensuse.org/download/repositories/KDE:/KDE4/ -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de

Am Wednesday 31 May 2006 10:35 schrieb Mathias Homann:

Adrian Schröter schrieb:

...

Am Wednesday 31 May 2006 05:41 schrieb Shriramana Sharma:

...

This is a really bad move. No FTP access, no development packages -- very bad publicity. :(

Hey, everything is still there, only at a different location and a README describes it.

no it is not.

under the old /supplementary/ tree there were packages for 9.2. those are gone.

9.2 would have been removed next quite soon, so we decided not to create it for now.

...

...

I was a regular updater -- even when people used to recommend the "virgin" distro for stability, I used to download the latest KDE updates eagerly. And now that's no more possible, or at least not as easy as before. Some hacks will be needed before I can conveniently download the base and application packages... But I want my Qt 4!

You get even a newer Qt 4 at

http://software.opensuse.org/download/repositories/KDE:/KDE4/

only if you run 10.1 which i wouldnt right now.

right, we can add 10.0 and 9.3 as well if there is some demand. -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de

Am Wednesday 31 May 2006 11:16 schrieb Marcus Meissner:

On Wed, May 31, 2006 at 11:13:00AM +0200, Adrian Schröter wrote:

...

Am Wednesday 31 May 2006 10:35 schrieb Mathias Homann:

...

Adrian Schröter schrieb:

...

Am Wednesday 31 May 2006 05:41 schrieb Shriramana Sharma:

...

This is a really bad move. No FTP access, no development packages -- very bad publicity. :(

Hey, everything is still there, only at a different location and a README describes it.

no it is not.

under the old /supplementary/ tree there were packages for 9.2. those are gone.

9.2 would have been removed next quite soon, so we decided not to create it for now.

In 7 months ... It is 9.1 that is scheduled to be removed soon.

that is true for security updates, not for supplementarry (9.1 did miss there already also). -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de

On Wed, 2006-05-31 at 10:35 +0200, Mathias Homann wrote:

Adrian Schröter schrieb:

...

Am Wednesday 31 May 2006 05:41 schrieb Shriramana Sharma:

...

This is a really bad move. No FTP access, no development packages -- very bad publicity. :(

Hey, everything is still there, only at a different location and a README describes it.

no it is not.

under the old /supplementary/ tree there were packages for 9.2. those are gone.

Has anyone actually tried to add the YaST2 repo: http://software.opensuse.org/download/repositories/<projectname>/<directory> Good luck as it is -NOT- YaST compatible. And no I should not have to report this as a bug as it should have been tested first.

From http://en.opensuse.org/Build_Service/User

YaST2 Only 10.0 and 10.1 YaST do support YUM repositories! For SUSE Linux 9.3, 10.0, 10.1 and Factory, you can also use smart or yum, to install and update packages from the Build Service. The latests smart and yum packages can be found at http://software.opensuse.org/download/home:/cthiel1/ A YaST user can add a project as installation source (In the "installation source" module) by using http://software.opensuse.org/download/repositories/<projectname>/<directory> I'm sorry but there is -no- <projectname> directory and pasting the link "http://software.opensuse.org/download/repositories/ in a browser comes back with a 404 error. Trying to add http://repos.opensuse.org/KDE:/KDE3/SUSE_Linux_10.0/ to YaST reports an error. There is -NO- add type for YUM repos on 10.0 "YaST2--> Installation Source". Someone want to try again. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On Wed, 2006-05-31 at 16:52 +0200, Marcus Rueckert wrote:

On 2006-05-31 10:31:50 -0400, Ken Schneider wrote:

...

A YaST user can add a project as installation source (In the "installation source" module) by using http://software.opensuse.org/download/repositories/<projectname>/<directory>

I'm sorry but there is -no- <projectname> directory and pasting the link "http://software.opensuse.org/download/repositories/ in a browser comes back with a 404 error.

Perhaps this could be fixed. We do need a starting point somewhere and it was not presented on the referring page. "<projectname>/<directory>" is -not- intuitive as a starting point if the base URL gives a 404 error.

...

Trying to add http://repos.opensuse.org/KDE:/KDE3/SUSE_Linux_10.0/ to YaST reports an error. There is -NO- add type for YUM repos on 10.0 "YaST2--> Installation Source". Someone want to try again.

i dont know your problem. but it works for me:

[[[ $ w3m -dump http://software.opensuse.org/download/repositories/

As someone else pointed out it reports an error when trying to add it using Yast2. I don't normally continue when I am presented with an error I abort. Perhaps a YOU update to the 10.0 package management system to include a "YUM" choice would be better I don't know. As far as the "w3m" command I have never seen it referenced before. You must remember that most people using 10.1 don't know how of these commands. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On Wed, 2006-05-31 at 17:33 +0200, Christoph Thiel wrote:

On Wed, 31 May 2006, Ken Schneider wrote:

<snip>

Just add "http://software.opensuse.org/download/KDE:/KDE3/SUSE_Linux_10.0/" as an installation source to SUSE Linux 10.0 -- YaST will figure out itself, it it's rpm-md or something else.

Thanks. I ignored the error and did continue and the repo was added. Perhaps the error could be better worded. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On Fri, 2006-06-02 at 07:32 +0300, Janne Karhunen wrote:

On Wednesday 31 May 2006 18:55, Kenneth Schneider wrote:

...

...

Just add "http://software.opensuse.org/download/KDE:/KDE3/SUSE_Linux_10.0/" as an installation source to SUSE Linux 10.0 -- YaST will figure out itself, it it's rpm-md or something else.

Thanks. I ignored the error and did continue and the repo was added. Perhaps the error could be better worded.

For me it does add the repos, but yast2 never exits 'installation source' menu after doing so (has to be killed).

There is no need to kill it, it just takes a long time to do its thing. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Am Wednesday 31 May 2006 02:03 schrieb Eberhard Moenkeberg:

On Wed, 31 May 2006, Pascal Bleser wrote: ...

...

- - please announce such stuff beforehand

Not enough; those "switch-movers" at SUSE have to learn other matters before they should get allowed to touch the switch: "vision" the situation at the remote sides.

...

I know Adrian has written 2 or 3 times that he wants to move suppl. KDE to the BS, but what you guys think is trivial and not important is actually being used by a vast number of SUSE Linux users out there. Some announcement, e.g. a week beforehand + published on the opensuse.org frontpage and feed, would have been desirable, to say the least ;)

The german word for such handicapped professionals is "Stuemper".

PROTEST!

okay, I take it that we could have made it in a better way. But a mail to the suse-mirror list was sent last week. (An announcement on opensuse-announce was unfortunatly not possible yesterday, because the KDE 3.5.3 was not meant for the public at that point of time) bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de

Martin Schlander wrote:

Quick question about the buildservice repos.

Is there an easy way to know who built what?

Though supplementary was unsupported I always took comfort in knowing it was built by SUSE packagers - and I considered it at least semi-official. Is there a way to assess the "risks" involved with the different repos on the buildservice? Or should everything just be considered 100% unofficial?

Martin / cb400f

giving that not anybody have access to the build service right now, I guess the actual users are good. this may become a problem one day. however it's an other subject jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

On 2006-05-31 14:47:31 +0200, Adrian Schröter wrote:

Am Wednesday 31 May 2006 13:04 schrieb Martin Schlander:

...

Quick question about the buildservice repos.

Is there an easy way to know who built what?

Though supplementary was unsupported I always took comfort in knowing it was built by SUSE packagers - and I considered it at least semi-official. Is there a way to assess the "risks" involved with the different repos on the buildservice? Or should everything just be considered 100% unofficial?

depends what you mean with unofficial. Supplementarry updates from ftp.suse.com were also unofficial from the view of SUSE.

However, you have valid point, is not obvious how much you can trust these packages. We do plan to create a user and trust system later this year where you can see how is creating these packages and what the community think about these people.

For now, only a limited number of people do have access and many of them are involved in the software projects they are building. So I doubt that someone has some interest to harm them. (Downloading, compiling and install the source has usually the same risk level).

and you can always report broken rpms on opensuse-packaging/opensuse-buildservice so we can take care of them and the packager. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org

Lenz Grimmer wrote:

Hi,

Janne Karhunen wrote:

...

...

Having dozens of different semi-working RPM frontends/repository types is getting seriously out of hands. You need to follow up latest developments on the front daily to be able to install anything. It doesn't really help the user anymore, quite the opposite.

I must admit I am getting the same impression. While it's nice to have options, I agree that it is getting out of hands. There is smart, apt-get, FOUS, rug, yum, YOU and whathavenot.

Please let some sanity prevail here :)

It would be nice to have *one* functional, integrated and supported tool to apply both updates and install packages from external repositories.

But it looks as if Zen/rug is supposed to take that role now, it just isn't fully there yet... Do you know that the package management made me re-think my long-standing SUSE usage? I really, really got frustrated with the state of package management in 10.1.

But yesterday evening I decided to give it a last try: I switched over to smart. And boy oh boy, what is smart a great tool! It works out-of-the-box, is fast (compared to zmd 'ultra-fast' :-), and there's even a KDE-native update notice application! Back to the topic: what is exactly the reason that development of yet-another-package-solution was started (zmd/rug) and so on where smart offers in my opinion a very well starting point... Regards Harry --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Michael Schroeder wrote:

On Fri, Jun 02, 2006 at 08:31:42PM +0200, Harry ten Berge wrote:

...

Back to the topic: what is exactly the reason that development of yet-another-package-solution was started (zmd/rug) and so on where smart offers in my opinion a very well starting point...

The reason is basically that the enterprise version needs some features that smart doesn't have. The most important one is the handling of "patches", i.e. groups of rpms. We need a way to make it possible for the admin to select/deselect such patches, e.g. when he decides that the patch is too unsafe for his critical application. Tools like smare just look at single rpms and check if a newer version is available or not. This is not enough for the enterprise.

Btw, zmd/rug is not a new thing, it is based on the red carpet system. What's new is the libzypp library.

Cheers, Michael.

Not to be cynical, but if it's not new, why doesn't it work properly? And, what I really can't understand, is the ignorance of the impact that the whole issue will have on the very good reputation that SUSE had in the past. Regards Harry --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

houghi wrote:

On Fri, Jun 02, 2006 at 08:50:23PM +0200, Harry ten Berge wrote:

...

Not to be cynical, but if it's not new, why doesn't it work properly?

That already has been explained and not only once.

...

And, what I really can't understand, is the ignorance of the impact that the whole issue will have on the very good reputation that SUSE had in the past.

What ignorance? People are awrae of the impact. The question is what we as a community can do to explain people what is happening and what is been done to solve it. (this is openSUSE, right?)

This is what I do 1) Explain what the problem is 2) Explain what the solution is for now 3) Explain what is being done to solve the issue.

It is as if a kid fell in the water and everybody is standing at the side saying how terrible it is and all the time the kid is drowning. So instead of standing at the side, jump in, or are you (multiple people) afraid to get wet?

No. Seriously. I'm not afraid to get wet. But the problem is that I find it at this stage difficult to handle your point 2 and 3. So what is being done about it? The only thing I'm hearing so far is that there will be an update any time soon. What is soon? But you're right about the community thing. That's why I asked what is wrong with smart. But that's clarified now... Besides that, I really don't know what we can do about it in the community. The one thing I can think of is a general discussion about package management for 10.2. I don't mean the technical implementation, because Novell has decided that zmd/rug is the solution. But the huge amount of different repository types, the way you must add additional repos.... For newbies (I've got some friends I convinced to try 10.1) it's way to difficult. That is something we think about in the community... Harry --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Marcus Meissner wrote:

...

So what is being done about it? The only thing I'm hearing so far is that there will be an update any time soon. What is soon?

Next week hopefully. We have a test repo online already and fixing the last critical bugs.

...

But you're right about the community thing. That's why I asked what is wrong with smart. But that's clarified now... Besides that, I really don't know what we can do about it in the community.

The one thing I can think of is a general discussion about package management for 10.2. I don't mean the technical implementation, because Novell has decided that zmd/rug is the solution. But the huge amount of different repository types, the way you must add additional repos.... For newbies (I've got some friends I convinced to try 10.1) it's way to difficult. That is something we think about in the community...

See opensuse-factory, where AJ started one...

Ok, I'll take a look... On a side note: do you know if there are plans to develop a KDE native updater applet? Regards Harry --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Marcus Meissner wrote:

On Fri, Jun 02, 2006 at 09:45:10PM +0200, Harry ten Berge wrote:

...

Marcus Meissner wrote:

...

...

So what is being done about it? The only thing I'm hearing so far is that there will be an update any time soon. What is soon?

Next week hopefully. We have a test repo online already and fixing the last critical bugs.

...

But you're right about the community thing. That's why I asked what is wrong with smart. But that's clarified now... Besides that, I really don't know what we can do about it in the community.

The one thing I can think of is a general discussion about package management for 10.2. I don't mean the technical implementation, because Novell has decided that zmd/rug is the solution. But the huge amount of different repository types, the way you must add additional repos.... For newbies (I've got some friends I convinced to try 10.1) it's way to difficult. That is something we think about in the community...

See opensuse-factory, where AJ started one...

Ok, I'll take a look...

On a side note: do you know if there are plans to develop a KDE native updater applet?

Yes. We even have found a student who wants to do it ;)

http://code.google.com/soc/suse/about.html

Btw, the previous YOU watcher just run a commandline program ("online_update")... It could be ported to just call "rug"... ;)

Ciao, Marcus

Thanks Marcus. Great to see this happening. I was becoming a little bit paranoid about the whole 'package management/gnome/kde' stuff. Am I correct to say that with the zmd/rug stuff you can actually push updates to machines? So it's not only polling for updates at the repository but a way to force this from a management console/gui thingy? Regards Harry --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Am Freitag, 2. Juni 2006 21:52 schrieb Marcus Meissner:

...

On a side note: do you know if there are plans to develop a KDE native updater applet?

Yes. We even have found a student who wants to do it ;)

http://code.google.com/soc/suse/about.html

Btw, the previous YOU watcher just run a commandline program ("online_update")... It could be ported to just call "rug"... ;)

How about patching the old SuSE-Watcher to just call smart .. That would be nice ;-) Greets Michael

Ciao, Marcus

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Lørdag 03 juni 2006 01:31 skrev Pascal Bleser:

If someone with some KDE hacking skills would like to spend a little time on it, I think it's pretty easy to expand (it already does the dirty job of interfacing with smart)... or even use SuSE-watcher and copy/paste the ksmarttray code "smart update" output checking code into it.

At least it would be nice to do a simple config dialog for the update interval (passing it from the command-line would be the easiest hack, but probably not the most noob-friendly).

Note that as smart is written in Python, a neat solution would be to code such a systray app (or kicker applet) in Python/QT or Python/KDE, to directly use the smart API instead of forking "smart update" and checking the output (although it works). But then again, Python/QT/KDE has very, very few documentation :\

Would be nice if you could tell ksmarttray to update certain channels (most notably ~/suse/update/10.1 of course) when checking for updates. I actually thought it did something like that - but after updating some channels manually I discovered a bunch of updates available ksmarttray hadn't told me about. Still pretty new Smart-user. Of course making an entire kde/qt port of the smart-gui would be very much appreciated also :) Martin / cb400f --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jdd wrote:

...

Would be nice if you could tell ksmarttray to update certain channels (most notably ~/suse/update/10.1 of course) when checking for updates.

and probably using different words for similar thinbgs add to the mess.

what are those channels? I already had problem undersdtanding what are the different inst-source (not even trying to know what are the different metadata systems)

The generic and most appropriate term is "repository". Well, the repository is on the server-side, for example: 1) http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1 2) http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS 3) http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386 (1) is a yast2 repository (2) is an RPM-MD (/repomd/yum, see below) repository (3) is an APT-RPM repository The following terms are used by different package managers and are all _references to repositories_. Such references usually contain information such as - - the base URL, where to retrieve the metadata and the packages - - a name but also additional information, depending on what the package manager is capable of handling. - - YaST2 calls them "installation sources" - - ZMD/rug calls them "catalogs" - - smart calls them "channels" (AFAICR, Red Carpet calls them "channels" as well) - - apt-rpm calls them "sources" - - yum calls them "repos" (repositories) but they're all the same thing: references to package repositories ;) Package repositories are made of "metadata". That metadata contains various information about the RPM packages that are available in a repository, such as: - - package name, version, release, target architecture, distribution - - summary, description, license, project website - - what it requires - - what it provides, and the list of files contained in the package That metadata information is needed by package managers like libzypp, ZMD/rug, apt-rpm, smart, yum, ... to be able to compute how to perform package installations, upgrades, removals (the requires/provides information is particularly important here). There are different metadata formats: - - RPM-MD (RPM-MetaData), also called "repomd" (Repository MetaData), also called "yum" (because its the native format for the yum package manager) - - yast2 - - apt-rpm (for RPM) and apt-deb (for DEB) - - Red Carpet (also called Open Carpet) - - RPM-HDL (RPM Header List) - - URPMI (for Mandriva's package manager) - - slack, for Slackware's "package manager" and maybe a few others. So, unfortunately, there's more or less a metadata format for every single package manager. It seems the NiH (*) syndrom has spread a lot amongst package manager developers ;) (*) "Not invented Here" Nowadays, most package managers seem to head for RPM-MD support, which is more or less becoming a standard: - - YaST2 supports it in SUSE Linux 10.0 - - libzypp supports it in SUSE Linux 10.1 - - yum supports it, obviously, it's the yum-specific format ;) - - apt-rpm supports it too, since one or two releases (not the version shipped with SUSE Linux 10.1 though) - - smart supports it, of course ;) (more information about that below) RPM-MD is represented in XML - actually, the repository metadata is stored in gzipped XML files, in a "repodata" subdirectory on the server (*), with the following files: - - repomd.xml: main repository file, very small, contains references to the others, as well as checksums and timestamps - - primary.xml.gz: contains the most important information: list of packages (with version, release, architecture), what it requires, size of the package, summary, description, etc.... - - filelists.xml.gz: contains the list of files that are included in the packages - - other.xml.gz: not used by all package managers, it contains the changelog information of every package (*) for an example: http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS/repodata/ Read here for more information on RPM-MD: http://linux.duke.edu/projects/metadata/ smart is a notable exception, because it supports *all* of the formats above (and it has no smart-specific format). When you add a smart "channel" (repository information), here are the types you can use (excerpt from "smart channel --help"): apt-deb - APT-DEB Repository apt-rpm - APT-RPM Repository deb-dir - DEB Directory red-carpet - Red Carpet Channel rpm-dir - RPM Directory rpm-hdl - RPM Header List rpm-md - RPM MetaData slack-site - Slackware Repository up2date-mirrors - Mirror Information (up2date format) urpmi - URPMI Repository yast2 - YaST2 Repository (note, I removed the *-sys channels, they represent the packages currently installed in the RPM database (or DEB database on Debian, etc...)) And yes, you can even mix them. In my list of channels for smart, I mix yast2, rpm-md and apt-rpm repositories. smart is even independent of the package subsystem, as it works for RPM (SUSE/Redhat/Fedora/Mandriva), Deb (Debian/Ubuntu) and Slackware. So you could install a .deb Debian/Ubuntu package on SUSE Linux with smart, but it wouldn't make any sense because it would be stored in a DEB package database... that knows nothing about the RPM database, etc... (so that usage is pretty pointless, and not the goal of smart anyway). Actually it's interesting because you can use smart (unmodified) on RPM, Deb and Slackware based distributions.

many things need to be simplified

Yes, or explained. Hope this helps. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEgXEJr3NMWliFcXcRAmoiAJsFBWG5nWjYaRmZkQqPISDNUj5q/gCdE2w5 DuPWXa1OOTtzLKU5ulKlP8g= =rGrM -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

On Sat, Jun 03, 2006 at 01:34:29PM +0200, jdd wrote:

I will certainly manage to make a wiki page with this (from the newbie point of view, and I will post the URL for you to fix errors :-)

Instead of making a new one, adapt the existing ones: http://en.opensuse.org/Installation_Sources http://en.opensuse.org/Package_Management and perhaps see that they also have "Additional info and links" so that they point to each other. There might be more info already available. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Am Samstag, 3. Juni 2006 01:31 schrieb Pascal Bleser:

Michael Schueller wrote:

...

Am Freitag, 2. Juni 2006 21:52 schrieb Marcus Meissner:

...

...

On a side note: do you know if there are plans to develop a KDE native updater applet?

Yes. We even have found a student who wants to do it ;)

http://code.google.com/soc/suse/about.html

Btw, the previous YOU watcher just run a commandline program ("online_update")... It could be ported to just call "rug"... ;)

How about patching the old SuSE-Watcher to just call smart .. That would be nice ;-)

That's what ksmarttray already does ;)

It's shipped as part of smart, in contrib/, and I package it as "smart-ksmarttray".

It's very simple though, it just calls "smart update" on a regular basis (interval is hardcoded in the sources), checks the output and reports it. So it's a lot like SuSE-watcher.

Hello Pascal, yes, ksmarttray is a lot like the suse-watcher, but what i actually wanted to say was, that there was, and is, a tool which has the flexibility in handling different kinds of sources. Which is well tested and accepted by the users. So, whatever zmd wanted to make better, or will do better in futur, this tool is simply not coming out of the comunity. It is against the meaning of opensource, and in this way i can not understand that NOVELL on on hand yells out OpenSource, and on the other hand fiddles somthing together behind close doors. It will never be accepted, and it will never be this well dokomented then smart. And this is a really bad Point. At least in germany it´s like that. When you buy somthing, even when it´s software, and it is not well dokumented, you can give it back, because it not useable. So, whatever the good thougts where, they should have never go this way. They should have taken something out of the comunity where they can say "we know that it´s working, and here you will find documentation about". Thats my point of this Thanks Pascal for keeping us up2date with smart (and others) Greets Michael

cheers

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schueller wrote:

Am Samstag, 3. Juni 2006 01:31 schrieb Pascal Bleser:

...

It's very simple though, it just calls "smart update" on a regular basis (interval is hardcoded in the sources), checks the output and reports it. So it's a lot like SuSE-watcher.

If someone with some KDE hacking skills would like to spend a little time on it, I think it's pretty easy to expand (it already does the dirty job of interfacing with smart)... or even use SuSE-watcher and copy/paste the ksmarttray code "smart update" output checking code into it.

if anybody would patch the suse-watcher to check about new updates with the smart engine, it would check the smart sources (channels=sources > jpp) for updates. If you then press the Button "Update now", the SuSE(Yast) Online Update would appear, which has mostly different sources. So it would only make sence when the hacked suse-watcher only checks the suse update repo, and for all other sources you can use ksmarttray...

Well, obviously suse-watcher should also be modified to start "smart - --gui" instead of YOU (but that's really the easy part) ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEgXFcr3NMWliFcXcRAnodAJ48K3m+vKubQhI8qgvcY0ExoofmxQCgiHXx CgNF28e5xSO/1hh7Ct+lO4Q= =RoCb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Op zaterdag 3 juni 2006 13:51, schreef Harry ten Berge:

What I would like to see that the SUSE specific channels you added to the package (thank you for that!) will be done in a separate package. So the distribution comes with a default package with the Smart tooling, and a separate package with all known additional distribution specific repositories.

Perhaps, a new a channel can be created that provides seperate rpms for each possible channel. For now let's call this channel 'channels'. So this channel provides e.g. the rpms: - channel-kde - channel-suser-guru - channel-packman etc The idea behind this is to be able to add a channel using the command: smart --install channel-<whatever name> Although, I'm not sure that this will actually add the channel, it would be nice if this was possible. By creating a new project 'channels' on the build server, it would be possible for build server users to maintain the channel rpm. Just an idea, perhaps it works...? -- Richard Bos Without a home the journey is endless --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Op zaterdag 3 juni 2006 15:45, schreef Pascal Bleser:

...

The idea behind this is to be able to add a channel using the command: smart --install channel-<whatever name>

It's even easier to provide .channel files somewhere (like the .repo files in the Build Service), and just do

smart channel --add http://......../guru.channel smart channel --add http://......../packman.channel

Not sure whether this is easier from a user perspective. In your case the user needs to remember the url pointing to the channel repository. In my proposal it is not needed to remember this. One could for example use smart's functionality to find the channel rpm. Once the correct rpm (providing the desired channel), just execute 'smart install channel-<name>'. Or the more lazy type of user could execute 'smart install '*<name>*.' and have the channel installed that way. The only requirement is to have all channel rpms in a common place. Just like the rpmkey rpms that I maintain at the moment. Your proposal just a *.channel repository is easier from a packager perspective, as there is not rpm needed. The advantage of having the channel files in an rpm, is that those gets updated automatically when the corresponding channel file gets updated. This is the same for the rpmkey rpms. The best place to host those channel rpms are of course suse itself as they get than mirrored automatically. But as you already stated that might not be possible due to law implications. I think that the buildserver could build/create a channel rpm for each project and have those stored in a central place. This would be a good start. -- Richard Bos Without a home the journey is endless --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Am Sunday 04 June 2006 00:34 schrieb Pascal Bleser:

Richard Bos wrote:

...

Op zaterdag 3 juni 2006 15:45, schreef Pascal Bleser:

...

...

The idea behind this is to be able to add a channel using the command: smart --install channel-<whatever name>

It's even easier to provide .channel files somewhere (like the .repo files in the Build Service), and just do

smart channel --add http://......../guru.channel smart channel --add http://......../packman.channel

Not sure whether this is easier from a user perspective. In your case the user needs to remember the url pointing to the channel repository. In my proposal it is not needed to remember this. One could for example use smart's functionality to find the channel rpm. Once the correct rpm (providing the desired channel), just execute 'smart install channel-<name>'. Or the more lazy type of user could execute 'smart install '*<name>*.' and have the channel installed that way. The only requirement is to have all channel rpms in a common place. Just like the rpmkey rpms that I maintain at the moment.

That's correct, good point. I'd rather name them smart-channel-* though ;)

...

Your proposal just a *.channel repository is easier from a packager perspective, as there is not rpm needed. The advantage of having the channel files in an rpm, is that those gets updated automatically when the corresponding channel file gets updated. This is the same for the rpmkey rpms.

Yep, you're right.

...

The best place to host those channel rpms are of course suse itself as they get than mirrored automatically. But as you already stated that might not be possible due to law implications.

s/might/will/

I started a thread/discussion with the SUSE folks about that when openSUSE started. I was asking them whether it would be possible to do some refinements in YaST2, to have it fetch a list of repositories from, say, opensuse.org and propose them to the end-user as additional repos.

It became pretty clear that it wouldn't be possible, because of ridiculous court rulings in the US and Germany (e.g. the Heise case), where "linking" to a resource that provides a package that under certain circumstances and/or jurisdictions would be.. well.. "attackable" in court, is already sufficient for potential trouble.

The issue was a task to.. mm.. I think it was Adrian, to take it to Novell's legal dept, but there was never any feedback on it (and it was in November 2005). Dunno if anything came back about that.. Adrian ?

The problem is that this decisions needs to be made for each software seperatly. For example it is very unlikely that this would be ever possible with DeCSS, but there are maybe chances for other stuff like mp3 playback. This will of course take much resources for each package at the legal department :/ bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

On Sun, Jun 04, 2006 at 12:54:11PM +0200, Pascal Bleser wrote:

Note, I'm not talking about building and hosting packages like mad in the Build Service, that's another topic.

... and another list <ducks> houghi -- This openSUSE mailinglist is about the community. All discussion about the community is welcome. If you have a techical question just subscribe via this email address: suse-linux-e-subscribe@suse.com, post your original email again there, and you will get a straight answer. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Op zondag 4 juni 2006 00:34, schreef Pascal Bleser:

...

I think that the buildserver could build/create a channel rpm for each project and have those stored in a central place.  This would be a good start.

It won't be in a central place, unfortunately.

In my phrase above, I referred to the projects that are build on the buildserver. I mean if the packages are allowed to be build on the buildserver, they are allowed to be distributed by by opensuse. Or are these 2 different animals? If all sofrtware build on the buildserver is allowed to be distributed by novell/opensuse, than it is also possible to create smart channel files/rpms for each of the projects hosted on the buildserver. Once an rpm is created it can be stored/movedto a common directory on the buildserver.

It could be done for repositories that don't contain stuff like mad or lame (which discards my repository and Packman, at the very least), like latest mozilla.org packages, latest wine packages by Marcus, latest OpenOffice.org packages, etc...

But the other ones must be hosted elsewhere.

See above. It's about the software provided via the buildserver. At the end it may result in 2 'smart-channel' repositories. One at the buildserver and another 1 hosted somewhere else, providing smart-channel rpms that are not possible to host on the buildserver.

Note that this structure would make it possible to host the/my smart RPMs in the openSUSE Build Service. I was very reluctant to the idea, and I'm still pretty sure it is going to make things more difficult for end-users but well... dunno... I'll think about it ;)

The point is that to install e.g. smart-channel-packman, you'll have to add the Packman repository in the first place, because it won't be hosted in the Build Service... chicken vs egg.

No, it will be different. Assume that there are 2 smart-channel directories (buildserver, and e.g. at packman). You should include those 2 channels by default in your smart rpm. The only thing the user now has to do to add packman is: smart install smart-channel-packman and packman is added.... :) In the same swing, one can execute: smart install smart-channel-bs-home:rbos (bs = buildserver) ps: is this discussion okay to be held here (opensuse = community) or should it be moved to somewhere else? -- Richard Bos Without a home the journey is endless --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

On Tue, Jun 06, 2006 at 01:38:51PM +0200, Klaus Kaempf wrote:

So you won't see SuSE/Novell offering such external links. However, we will support a standard way of repository linking in the future.

Here I am telling everybody it is SUSE not SuSE and then I see people from SUSE writing SuSE instead of SUSE. :-( houghi -- This openSUSE mailinglist is about the community. All discussion about the community is welcome. If you have a techical question just subscribe via this email address: suse-linux-e-subscribe@suse.com, post your original email again there, and you will get a straight answer. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

On Jun 06, 06 20:16:55 +0200, houghi wrote:

On Tue, Jun 06, 2006 at 01:38:51PM +0200, Klaus Kaempf wrote:

...

So you won't see SuSE/Novell offering such external links. However, we will support a standard way of repository linking in the future.

Here I am telling everybody it is SUSE not SuSE and then I see people from SUSE writing SuSE instead of SUSE. :-(

Within SUSE, there is a secret brotherhood of traditionalists called SuSE. :-) please have mercy, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

On 2006-06-06 20:16:55 +0200, houghi wrote:

Here I am telling everybody it is SUSE not SuSE and then I see people from SUSE writing SuSE instead of SUSE. :-(

you are sooooooooooooo wrong: it is S.u.S.E. scnr darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harry ten Berge wrote:

Pascal Bleser wrote:

...

Michael Schueller wrote:

...

...

...

It's very simple though, it just calls "smart update" on a regular basis (interval is hardcoded in the sources), checks the output and reports it. So it's a lot like SuSE-watcher.

If someone with some KDE hacking skills would like to spend a little time on it, I think it's pretty easy to expand (it already does the dirty job of interfacing with smart)... or even use SuSE-watcher and copy/paste the ksmarttray code "smart update" output checking code into it. if anybody would patch the suse-watcher to check about new updates with the smart engine, it would check the smart sources (channels=sources > jpp) for updates. If you then press the Button "Update now", the SuSE(Yast) Online Update would appear, which has mostly different sources. So it would only make sence when the hacked suse-watcher only checks

Am Samstag, 3. Juni 2006 01:31 schrieb Pascal Bleser: the suse update repo, and for all other sources you can use ksmarttray...

Well, obviously suse-watcher should also be modified to start "smart --gui" instead of YOU (but that's really the easy part) ;)

I would really *love* that!

Since thursday I'm a new Smart lover,

*g* yet another lover, smart sure is a busy h...er ;)))

And the main reason I like it so much (besides the fact that it actually works perfectly ;-) is that it provides a distribution-independant solution. I think that this is good for general acceptance of Linux on the desktop. No need to re-invent the wheel everytime...

Absolutely, from that point of view, smart has a huge potential. While it will most probably never become the "default" package manager on all distributions, it is nevertheless available for all distributions, and you can use it everywhere. Same tool, same commands, and the same frontends. Actually, one could write a more capable GUI for package management, based on smart, which would work on any distribution. Personally, I'm rather focusing on smart on SUSE Linux, but the potential is there ;)

What I would like to see that the SUSE specific channels you added to the package (thank you for that!) will be done in a separate package. So the distribution comes with a default package with the Smart tooling, and a separate package with all known additional distribution specific repositories.

- From a technical point of view, I would tend to agree. But not for the sake of end-users, at least for the less experienced. Installing smart on 10.1 currently already is pretty much jumping into hoops for beginners (especially when zypp doesn't work :\), mostly for installing python-rpm first (smart depends on it, and it's not installed by default). Then they have to install smart. Having to install another package (e.g. "smart-suse") will make the procedure even longer (and possibly more complex): http://spinink.net/2006/05/20/installing-smart-package-manager/ http://dev-loki.blogspot.com/2006/05/how-to-install-and-use-smart-on-suse.ht... http://www.desktoplinux.com/articles/AT3456783210.html Another option would be to write some good bash script that would handle all the nitty-gritty, and less experienced users would just need to run that. wget http://......./smart-install-suse.sh bash ./smart-install-suse.sh It would check for rpm-python, install it if it's not present, grab the latest smart RPM, and then the latest smart-suse RPM. Having to run a shell-script that you grab from the internet as root is certainly not the most secure way of doing things, but in the end, people have to trust those who build the packages anyway (but at least packages have signatures and checksums). Apart from that, I would have to split out another subpackage for things that were previously contained in the "main" package. That's going to be an issue for people who already have smart installed and upgrade to that version. I'm not sure I like it.

But first we need a KDE Smart gui :-)

Well, yeah, possibly. Though that's not really high priority IMO. A good GUI, whatever the toolkit is, be it GTK2 or QT/KDE. Even though I use KDE as my desktop environment, I don't really care if the GUI uses GTK2, as long as its good. But I always use "smart --shell" so I won't care about that in the first place ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEgY22r3NMWliFcXcRAtjoAJsExenzJqPh1mxBaKc8oMmekeIgHQCgsT1Q 5LGBxwcB2HB4cla+/Pf/8Wo= =FW4k -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

houghi wrote:

[...] What ignorance? People are awrae of the impact. The question is what we as a community can do to explain people what is happening and what is been done to solve it. (this is openSUSE, right?)

Maybe some ignorance at the management level. You're right that we're no longer able to fix the errors that have been made prior to the 10.1 release - so at the moment we can only explain what happened, we can try to provide information to work around some of the problems, and we can try to track down all the issues and help to solve them. I am sure that many developers at Novell/SUSE currently work on fixing the remaining problems. Nevertheless, it's a bad situation and I am sure SUSE Linux has lost some reputation. Therefore, from the community's point of view it's also important to ensure that we will not face a situation like that again! This means, for instance, it's important to convince those people at Novell/SUSE in charge of the release that major changes in a late beta stage are not acceptable from a user's perspective. In our company, nobody would come up with an idea to make major changes in such a late stage of the development process - this was like calling for problems and trouble... Cheers, Th. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

* Harry ten Berge <htenberge@gmail.com> [Jun 02. 2006 20:50]:

...

Not to be cynical, but if it's not new, why doesn't it work properly?

The components are not new but their integration is.

And, what I really can't understand, is the ignorance of the impact that the whole issue will have on the very good reputation that SUSE had in the past.

Be assured that we do not ignore this issue. However, we have to be very careful on making changes to the system as we want to fix bugs and not introduce new ones. Klaus ---------------------------------------------------------------------- Klaus Kämpf, Architect Systems Management, Research & Development SuSE Linux Products GmbH, Maxfeldstrasse 5, 90409 Nürnberg, Germany kkaempf@suse.com ---------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org