Mailinglist Archive: opensuse-buildservice (253 mails)

< Previous Next >
Re: [opensuse-buildservice] how to carefully push a package
  • From: Detlef Steuer <detlef.steuer@xxxxxxxxxxxxxx>
  • Date: Fri, 24 Nov 2006 13:40:11 +0100
  • Message-id: <20061124134011.2a75aa65.detlef.steuer@xxxxxxxxxxxxxx>
Hi and thx a lot for the answers!

On Fri, 24 Nov 2006 12:53:04 +0100
Henne Vogelsang <hvogel@xxxxxxxxxxxx> wrote:

> Hi,
> On Thursday, November 09, 2006 at 16:29:14, Detlef Steuer wrote:
> > into inclusion in the main distribution? Are there defined milestones
> > a packages must pass? (Besides a clean build, of course.) What are
> > showstoppers?
> >
> > Is there a predefined way to work a package`s way up into OpenSuse?
> > Or does the intention to include packages from BS into OpenSuse even
> > exist?
> Up till now there is no defined way to include packages from the
> buildservice into the distribution. The way to go is to enter the
> project into the wishlist on the wiki and provide a link to the
> buildservice project. We will then pick the package up and work with the
> BS maintainers for inclusion.

Ok, it is on the wishlist and link is provided. Someone else already did that. Fine!

> But we thought about this a lot. The goal is to make this process as
> comprehensible, objective, scalable and living as possible. Here is the
> "plan" we have how we would like to do this:
> Package Attributes
> ------------------
> Each package has N attributes. There are different kinds of attributes.
> Bolean (yes/no), Alternative (a, b, c,), Score (0-10) and so on.
> Examples:
> popularity=8
> osi_approved=yes
> upstream_active=no
> novell_maintained=yes
> only_package_that_provides_this_functionality=yes
> stability=experimental
> classification=addon
> maintenance=moderate
> bugs=7
> security_updates=0
> Input Providers
> ---------------
> Each Attribute has an input provider. Input providers can be all kind of
> things.
> Examples:
> humans:
> o maintainer
> o author
> o user
> o legal
> o and so on
> programms:
> o download.o.o
> o YaST
> o License Digger
> o Wishlist (Fate)
> o bugzilla
> o vote tool
> o and so on
> Attribute aggregation
> ---------------------
> A distribution is an attribute aggregation. Think of it as a rule sheet.
> Set by the distributions project manager. In case of openSUSE this would
> be AJ. In case of Steuerlinux powered by openSUSE this would be you.
> Example:
> if classification equals core then
> stability needs to be rocksolid or
> only_package_that_provides_this_functionality needs to
> be yes
> novell_maintained needs to be yes
> if stability equals experimental then
> bugs need to be less than 15 and
> security_updates need to be less than 4
> if only_package_that_provides_this_functionality equals no then
> popularity needs to be more than 6
> if name equals glibc then
> project needs to be novell:glibc
> It is a long way to go before we can make this happen but we are working
> on it. The thing is, it is already working like this. Kind of. Just
> without the attributes, input providers and rules sets expressed
> somewhere. It all happens in some inter-human conversation or in
> someones head.

Ok , I understand the way you want to go. It looks a bit complicated to handle, if you really want to have lots of distributions. I don´t know for other packages and maintainers but I would be very glad, if there was a centralized repository for add-ons, at least as an intermediate step. So users would get their hand on OpenSuSE, install the core distribution, add a repository (or that repository is compiled into yast beforehand) and after the first login they have another 20000 packages to choose from without having to search for, like say Ubuntu Universe. That searching is where people are having problems right now. The BS nearly is such a repo, but you have to know where to look.
Well, most probably you discussed such a set-up, too.
I don´t think that many people are interested in providing a complete, specialized distribution, that is after doing it _once_ just "because you can", but may be I´m wrong here.

Thx again for the explanation!


> The next step will be to solidify attributes, input providers and a rule
> sheet from the existing distribution. Once we have that first set, we can
> extend and particularize it.
> Henne
> --
> Henne Vogelsang, Core Services
> "Rules change. The Game remains the same."
> - Omar (The Wire)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
> For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >