[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)

Hi Emmanouil,

On Wed, Jul 24, 2013 at 01:22:37PM +0300, Emmanouil Kiagias wrote:
> > That's fine.  Anything we should know here from this conference?
> >
> No I don't think so. There were some interesting talks like: advice for
> freelancing, measure  I/O latency in cloud systems. And generally talks
> about the openSUSE community itself.

Thanks for the summary.

> > I think this is perfectly OK.  If a package is not available for a
> > certain architecture this is for a reason.  Chances that you can obtain
> > the package from any other external source are very close to zero - so
> > suggesting those packages for architectures is totally useless.
> > Actually when thinking twice about it it is the correct way to *not*
> > suggest packages that exist for other architectures for a certain
> > architecture where the package does not exist.
> >
> Hmm, I didn't think of this. I'll keep that in mind also for the existing
> {sec-}blend-gen-control


> > I'm not fully sure whether I understand the question correctly so I try
> > to rephrase:
> >
> >   1. Yes, we want recommends of certain packages (no depends)
> >   2. Yes, we want to exclude certain architectures if the package does
> >      not exist here.
> >   3. A package should not show up in Suggests if it exists for one
> >      single architecture (at least)
> >   4. Item 3. should even apply if we consider the control.<arch>
> >      approach we previously considered - there is no point in suggesting
> >      a package if there seem to be reasons why a certain architecture
> >      does not feature this software.
> >
> I will implement the new single control file approach as you mention into
> the rephrase items.


> For the moment I will keep the existing {sec-}blend-gen-control as is
> concerning the Depends packages which move to Suggests when they are not
> available for a specific arch. Later we can reconsider it and change it.

That's perfectly in line with what I would do.  If we succeed with the
single control file approach we will probably follow this path and
fixing things we will finally not use makes it more or less a waste of

Kind regards



Reply to: