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

Bug#825004: blends-dev: undesired new Task $blend-all package

Hi Ole,

adding the debian-edu list to cc: (and keeping more context quoted) as this
is quite relevant for us…

On Sun, May 22, 2016 at 09:02:36PM +0200, Ole Streicher wrote:
> Hi Holger,
> Am 22.05.2016 um 12:45 schrieb Holger Levsen:
> > since 0.6.93 blends-dev creates a new $blend-all package which is *not*
> > useful for all blends, so there should be a way to disable that.
> > 
> > In the case of debian-edu it creates an education-all package which
> > depends on packages which conflict which each other (eg standalone and
> > main-server, but there are more).
> > 
> > For the Debian Edu usecase such a $blends-all package must not be created.
> > 
> > Please make this behaviour optional and opt-in. As it stands this is a
> > major regression on the usability of the package.
> I am not sure whether I understand you specific problem correctly: Do
> you want to have a way to select individual tasks, or a way to disable
> it for the whole blend?

We dont want a broken and uninstallable education-all package.

Right now this breaks building the debian-edu package from source in sid
for us. (Well, or rather it breaks the prequisite, the make dist step.)
> The first option is already there, although opt-out: You may specify an
> "Install: False" in the task header, and the task will not be in the
> list. The idea of opt-out was that usually our packages should not
> conflict, and harddisk space is not expensive anymore. So having
> additional unused packages is better than missing expected packages. But
> this may be changed ofcourse, if we agree on that (I can live well with
> both).
> The second option (don't create the -all task at all) is not there yet.
> It could be done implicitely: if all tasks have "Install: false" (resp.
> no task has "Install: true" if we agree on this), then the -all task
> would be empty and could just be not created. If you agree here, I could
> it implement this way; but maybe I would need to request some help since
> my Perl knowledge (the logic in blends-dev is implemented in Perl) is
> !"§&&*'.
> Disabling the -all package completely would however mean that in the
> however-it-is-implemented "blends" selection during installation
> (discussed in #758116), selecting this task would install no additional
> packages, so it would probably wise to remove it there as well.

the implementation of #758116 is still in flux, so I would like to
suggest a third option: allow to install something else than
"blends-all" from tasksel.

Because we already have these metapackages which are suited for that, we
just dont have an education-all metapackage because that's simple not
useful for us.

What comes _close_, is education-standalone, possibly combied with

But then it would also be great, if it were possible to install
education-mainserver or education-thin-client-server.

And some more. Actually, best have a look at
to see the options we currently have.

So, to sum up:

option 1 is not useful for us, there is no "education-all" metapackage
which would be a sensible choice.

option 2 is something which makes sense to us. (I repeat: the current
implementation broke our workflow to do releases in sid.)

but then, we also want to be presented as part of the blends presented
via regular d-i (#758116), so I think it would be best to allow other
packages than %blends-all to be presented there.


Attachment: signature.asc
Description: Digital signature

Reply to: