Lars Vogdt ha scritto:

What about creating a "pseudo" package like the gcc people do? -------------- %package libopenbabel Requires: libopenbabel3

%files libopenbabel %defattr(-,root,root) %doc README.SuSE

%package libopenbabel3 Provides: libopenbabel2 = %version Obsoletes: libopenbabel2 < %version -------------- Other packages just need to have Requires: libopenbabel in their dependencies - the pseudo package will then require the correct library version (so in the future, just change it to: %package libopenbabel Requires: libopenbabel4 for example - no other changes in other packages have to be done.

What do you think about this?

and what's the problem?

Yes. I'm creating Beta1 for openSUSE 11.0 right now. ;-)

I've also added a new package called "opensuse-education-release" which is always installed now. This package comes with an own file: /etc/openSUSE-Education-release so anyone can know on which version he is just looking into this file. Another idea for this package can be found in /etc/zypp/* => a products definition for upcomming zypper and YaST features => a vendor file, so packages from openSUSE-Education will be handled as official openSUSE packages during an update => an online update repository (see below)

Currently, the online update repository is empty (what a surprise ;-). I'm currently not shure if we want to go this way, but it looks to me like a good way as we can go the "official" way with a frozen main repository and just updates for packages with bugs - including an information file (Patchinfo) giving users a human readable information of what is fixed.

Problem: Somebody has to write such a "Patchinfo" file - normally the packager who updates the package should do this as he's the one who should know all about the update. So this would be extra work for each packager: not only handling bugzilla entries and fixing packages: now even writing patchinfos and releasing updates.

Currently, I like the Fedora way using a webfrontend for this: https://admin.fedoraproject.org/updates which is "bodhi" => https://fedorahosted.org/bodhi/wiki

But again: this needs additional work for every packager who needs to release a fixed package - so I need your "GO" to implement this for openSUSE-Education. What's your opinion?

With kind regards, Lars

great! you are always the best!Lars Vogdt ha scritto:

Hi Andrea

Thanks for all your hard work!

On Do 10 Jul 2008 15:22:42 CEST Andrea Florio wrote:

...

Hi Folks, openbabel 2.2.0 STABLE has been built.

This mail is just to inform an important change, infact we have no more

libopenbabel2 but now thereis libopenbabel3 that of course "obsoletes" and "provides" libopenbabel2.

What about creating a "pseudo" package like the gcc people do? -------------- %package libopenbabel Requires: libopenbabel3

%files libopenbabel %defattr(-,root,root) %doc README.SuSE

%package libopenbabel3 Provides: libopenbabel2 = %version Obsoletes: libopenbabel2 < %version -------------- Other packages just need to have Requires: libopenbabel in their dependencies - the pseudo package will then require the correct library version (so in the future, just change it to: %package libopenbabel Requires: libopenbabel4 for example - no other changes in other packages have to be done.

What do you think about this?

...

I'm proud to annunce that DIDASCA ( http://www.didasca.it/ ) use on their "Progetto Lazzaro" ( http://www.progettolazzaro.it/ ) openSUSE and LTSP like instrumets to recovery obsoletes LANs and PCs

Goals of prjects are to make Italian schools able to use LTSP on theier Education Enviroment with support of Italian "Education Ministry".

I'm waiting for more and better infos but all the projects sound a greate way to improve Linux use on Education Enviroments and also to make our openSUSE better known.

Very cool!

...

So... We must work hard to end openSUSE 11.0 EDU-CD on time.

Yes. I'm creating Beta1 for openSUSE 11.0 right now. ;-)

I've also added a new package called "opensuse-education-release" which is always installed now. This package comes with an own file: /etc/openSUSE-Education-release so anyone can know on which version he is just looking into this file. Another idea for this package can be found in /etc/zypp/* => a products definition for upcomming zypper and YaST features => a vendor file, so packages from openSUSE-Education will be handled as official openSUSE packages during an update => an online update repository (see below)

Currently, the online update repository is empty (what a surprise ;-). I'm currently not shure if we want to go this way, but it looks to me like a good way as we can go the "official" way with a frozen main repository and just updates for packages with bugs - including an information file (Patchinfo) giving users a human readable information of what is fixed.

Problem: Somebody has to write such a "Patchinfo" file - normally the packager who updates the package should do this as he's the one who should know all about the update. So this would be extra work for each packager: not only handling bugzilla entries and fixing packages: now even writing patchinfos and releasing updates.

Currently, I like the Fedora way using a webfrontend for this: https://admin.fedoraproject.org/updates which is "bodhi" => https://fedorahosted.org/bodhi/wiki

But again: this needs additional work for every packager who needs to release a fixed package - so I need your "GO" to implement this for openSUSE-Education. What's your opinion?

With kind regards, Lars

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