Mailinglist Archive: opensuse-edu (60 mails)

[Andrea Florio <andrea@xxxxxxxxxxxx>]

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 <andrea@xxxxxxxxxxxx>
> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-edu+help@xxxxxxxxxxxx