Re: Bug#825004: workaround for src:debian-edu for 825004 (was Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading f

[Ole Streicher]

Holger Levsen  writes:
> On Tue, May 24, 2016 at 01:42:48PM +0200, Andreas Tille wrote:
>> I've seen Ole busy commiting changes to Git in the direction of
>> fixing this. :-)
>
> oh, cool, looking forward to those! :)

They are in the git already. Please do and allow some testing however
before we create a new release.

Cheers

Ole

Re: Bug#825004: workaround for src:debian-edu for 825004 (was Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading f

[Holger Levsen]

On Tue, May 24, 2016 at 01:42:48PM +0200, Andreas Tille wrote:
> I've seen Ole busy commiting changes to Git in the direction of
> fixing this. :-)

oh, cool, looking forward to those! :)

thanks!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Ole Streicher]

Andreas Tille  writes:
>> thinking about it…: we can't do this, as changes have to be in sid
>> before they are accepted in stable. As we cannot have this change in sid
>> atm (#825004) we cannot really have this in jessie now neither… sigh.
>> 
>> So let's wait for a fix for #825004 first.
>
> Depending how fast you need a solution you could easily add another sed
> call in the new dist target to work around #825004.  Feel free to ask me
> for another patch.  Its not the best method to work around but it would
> definitely work.  I'd add a bit of documentation to the Makefile and
> also a README.source.  Just let me know if I should push this right into
> Git.

I reversed now the behaviour of the flags in blends-dev, so that tasks
are *only* installed if they have an "Install: true" in the
header. Also, the -all package is only created if there was any task
with the "Install: true". This should solve the problem, so that a
workaround is not needed.

I would, however, also change the debian-blends-tasks.desc so that the
"-all" file is the key (not the -tasks file, as it is in the
moment). This would disable all blends in the installer that haven't
anything to install yet. For Debian-Edu (and others wishing their own
solution here): please edit the file afterwards and put there whatever
should be in there.

Objections on that?

Best regards

Ole

Re: Bug#825004: workaround for src:debian-edu for 825004 (was Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading f

[Holger Levsen]

Hi Andreas,

On Tue, May 24, 2016 at 12:24:26PM +0200, Andreas Tille wrote:
> > That would be much appreciated indeed. (Aka: Could you please give us
> > such a patch?!)
> Commited to Git.

thanks. 

I've seen you also added a "closes: 825004" to our debian/changelog,
which I've rewritten to "workaround #825004" as that bug is about
blends-dev not having an option not to create an $blends-all
metapackage.
 
> Please note:  The patch only removes edu-all.  There are also changes inside
> the tasksel control file which you might or might not have noticed.
 
yes, i've seen those, thanks for notifiying anyway. I've just not made
up my mind how to react to those…

> Hope these small workarounds are helpful

they are, thanks. But as you say, they are just workarounds, the bugs
/ missing features still reside in blends-dev.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#825004: workaround for src:debian-edu for 825004 (was Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading f

[Andreas Tille]

Hi Holger,

On Tue, May 24, 2016 at 09:14:19AM +, Holger Levsen wrote:
> On Tue, May 24, 2016 at 10:50:30AM +0200, Andreas Tille wrote:
> > Depending how fast you need a solution you could easily add another sed
> > call in the new dist target to work around #825004.  Feel free to ask me
> > for another patch.  
> 
> That would be much appreciated indeed. (Aka: Could you please give us
> such a patch?!)

Commited to Git.
 
> > Its not the best method to work around but it would
> > definitely work.  I'd add a bit of documentation to the Makefile and
> > also a README.source.  Just let me know if I should push this right into
> > Git.
> 
> Yes, please commit and push this to our git repo. If you are confident in the
> solution, please use the master branch in git, else use a branch
> andreas/825004 or some such :-)

I thinks there is no need to fiddle around with branches for a single sed
statement.

My later commit regenerated the source tarball since the change in d/control
needed to be added there.

Please note:  The patch only removes edu-all.  There are also changes inside
the tasksel control file which you might or might not have noticed.

Hope these small workarounds are helpful

  Andreas.

-- 
http://fam-tille.de

Re: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Andreas Tille]

Hi Ole,

On Tue, May 24, 2016 at 09:51:09AM +0200, Ole Streicher wrote:
> Andreas Tille  writes:
> > Since a long time I'm wondering whether we should craft tasks files to
> > express what we "really" want (like specifying mostly all dependencies
> > as "Recommends" and leave the "Depends" for what we really mean as
> > Depends.  Since there are the frequently discusses drawbacks and
> > compatibility issues with the current tasks files this is nothing that
> > should be done quickly.
> 
> Why not?

Your proposal is very good but not *quick*. ;-)

> In my opinion it is quite straightforward, *and* we get a
> documentation as a nice bonus: /read all imperatives below as "we should" ;-)/
> 
> * Create a document that describes the (new) format, and put it on
>   blends.d.o. The first line of the new format should be
>   "Format: http://blends.debian.org/tasks-format/1.0;
> 
> * Extend the parser in blends-dev and in webtools to recognise this line
>   and use it as switch between current and new format
> 
> * Start to convert the own blends. This probably is as simple as a
>   couple of simple sed scripts.
> 
> * Identify all build-depends of blends-dev, apply the sed scripts to get
>   a patch, and file bug reports for them
> 
> This does not look like really difficult; probably the hardest part is
> to review the current format.

Its not difficult - it just needs to be done.  I'm currently doing a
very bad job in the latter.  For instance using the code developed in
GSoC *three* years ago[1] is also not really difficult.  It just needs
more testing which I always pushed to "some later point in time not that
close to a release."  Meanwhile we are developing two parallel toolsets
(blends-dev and the webtools) in parallel since we do not get the
enhanced tools into production.  I'd hesitate to implement your
suggestion in two code bases.

> Aside from the changes
> 
> Recommends: --> Suggests:

I think Recommends should stay Recommends.

> Depends: --> Recommends:

+1

> new Depends: for real hard dependencies

+1

> I would f.e. propose to do as well in this step:
> 
> Pgk-Description: --> Description
> Pkg-Url --> Url (or consequently use Homeppage:)

Fine for me but we need to find a new field name for the Description of
the metapackage itself (which was the reason why the Pkg- prefix was
invented once prospective packages came up inside tasks files).
 
> and would also include the changes needed to include a default selection
> of packages as installation option for the Debian installer (currently
> an optional "Install: false", but see bug #825004, and also see the
> discussion in bug #758116).

Fine for me.
 
> These steps will make the change possible, bring inform the dependencies
> nicely (with a patch) about the change, and finally allows to stick them
> with the old format if there are good reasons for it (f.e. if the depend
> on the old format elsewhere).

Currently I do not see any reason why we should depend from the old
format.

> Unsolved in this scheme is the integration into the blends-dev document;
> maybe it could just link to the document. If we create the format spec
> in .rst or .md, we can easily also provide a web-readable version.
> 
> What do you think?

I think we should *first* bring blends-dev 0.7[2] and the UDD based
webtools into production.  This would enable us to have only a *single*
point of changes for your proposal since we only need to fix the UDD
importer.  Anything else is normalised via UDD.  And as I said in the
beginning that's not really "quick".

But yes, I like your suggestions a lot in general.

Kind regards

  Andreas.

[1] git://anonscm.debian.org/blends/blends-gsoc.git 

-- 
http://fam-tille.de

Bug#825004: workaround for src:debian-edu for 825004 (was Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from

[Holger Levsen]

Hi Andreas,

On Tue, May 24, 2016 at 10:50:30AM +0200, Andreas Tille wrote:
> Depending how fast you need a solution you could easily add another sed
> call in the new dist target to work around #825004.  Feel free to ask me
> for another patch.  

That would be much appreciated indeed. (Aka: Could you please give us
such a patch?!)

> Its not the best method to work around but it would
> definitely work.  I'd add a bit of documentation to the Makefile and
> also a README.source.  Just let me know if I should push this right into
> Git.

Yes, please commit and push this to our git repo. If you are confident in the
solution, please use the master branch in git, else use a branch
andreas/825004 or some such :-)

Thanks!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Andreas Tille]

Hi Holger,

On Tue, May 24, 2016 at 08:28:35AM +, Holger Levsen wrote:
> control: block 793667 by 825004
> thanks
> 
> On Tue, May 24, 2016 at 07:53:05AM +, Holger Levsen wrote:
> > thanks for the patch, though #825004 has broken the "dist" target for us
> > in sid…
> > 
> > I'll think whether I want to use this to fix this issue (#793667) in jessie
> > though.
> 
> thinking about it…: we can't do this, as changes have to be in sid
> before they are accepted in stable. As we cannot have this change in sid
> atm (#825004) we cannot really have this in jessie now neither… sigh.
> 
> So let's wait for a fix for #825004 first.

Depending how fast you need a solution you could easily add another sed
call in the new dist target to work around #825004.  Feel free to ask me
for another patch.  Its not the best method to work around but it would
definitely work.  I'd add a bit of documentation to the Makefile and
also a README.source.  Just let me know if I should push this right into
Git.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Processed: Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Debian Bug Tracking System]

Processing control commands:

> block 793667 by 825004
Bug #793667 [education-main-server] gosa-plugin-netgroups not pulled-in when 
upgrading from Debian Edu squeeze mainserver
793667 was not blocked by any bugs.
793667 was not blocking any bugs.
Added blocking bug(s) of 793667: 825004

-- 
793667: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793667
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: #793667: forced depends (instead of recommends) using blends-dev

[Ole Streicher]

Petter Reinholdtsen  writes:
> The tasksel description files have a "Key" concept, which if I remember
> correctly is packages that must be available for the task to show up.
> As such they behave a bit like depends for metapackages, where the
> metapackage is uninstallable if some dependency is missing.
>
> Perhaps we can introduce a Key: keyword in the blends task files and map
> it to Key: in the tasksel description file and depends in the
> metapackage?  It would avoid breaking existing blends tasks and give us
> a way to enforce that a package is pulled in during upgrades.

We could map the (new) "Depends:" packages in the task to the Key:
list in the debian--tasks.desc file (and to Depends: in the
metapackage itself). This would prevent uninstallable tasks from showing
up.

> It would also introduce a hard dependency between a package and the
> task, exactly the kind of link we wanted to avoid when deciding to make
> all task packages recommends or suggests, so it should be used with care
> to avoid getting a task thrown out of testing needlessly when some nice
> to have but not vital package is removed from testing.

The proposal for debian-edu does exactly this: introduce a hard
dependency, with all its advantages and drawbacks. When looking into the
bug, this seems to be the intention.

Best regards

Ole

Re: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Ole Streicher]

Andreas Tille  writes:
> Since a long time I'm wondering whether we should craft tasks files to
> express what we "really" want (like specifying mostly all dependencies
> as "Recommends" and leave the "Depends" for what we really mean as
> Depends.  Since there are the frequently discusses drawbacks and
> compatibility issues with the current tasks files this is nothing that
> should be done quickly.

Why not? In my opinion it is quite straightforward, *and* we get a
documentation as a nice bonus: /read all imperatives below as "we should" ;-)/

* Create a document that describes the (new) format, and put it on
  blends.d.o. The first line of the new format should be
  "Format: http://blends.debian.org/tasks-format/1.0;

* Extend the parser in blends-dev and in webtools to recognise this line
  and use it as switch between current and new format

* Start to convert the own blends. This probably is as simple as a
  couple of simple sed scripts.

* Identify all build-depends of blends-dev, apply the sed scripts to get
  a patch, and file bug reports for them

This does not look like really difficult; probably the hardest part is
to review the current format. Aside from the changes

Recommends: --> Suggests:
Depends: --> Recommends:
new Depends: for real hard dependencies

I would f.e. propose to do as well in this step:

Pgk-Description: --> Description
Pkg-Url --> Url (or consequently use Homeppage:)

and would also include the changes needed to include a default selection
of packages as installation option for the Debian installer (currently
an optional "Install: false", but see bug #825004, and also see the
discussion in bug #758116).

These steps will make the change possible, bring inform the dependencies
nicely (with a patch) about the change, and finally allows to stick them
with the old format if there are good reasons for it (f.e. if the depend
on the old format elsewhere).

Unsolved in this scheme is the integration into the blends-dev document;
maybe it could just link to the document. If we create the format spec
in .rst or .md, we can easily also provide a web-readable version.

What do you think?

Best regards

Ole

Re: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Holger Levsen]

Hi Andreas,

On Tue, May 24, 2016 at 08:51:51AM +0200, Andreas Tille wrote:
> You can do this with the attached patch overriding the dist target to
> afterwards change the d/control file.  Feel free to `git am` into the
> repository.

thanks for the patch, though #825004 has broken the "dist" target for us
in sid…

I'll think whether I want to use this to fix this issue (#793667) in jessie
though.

> Since a long time I'm wondering whether we should craft tasks files to
> express what we "really" want (like specifying mostly all dependencies
> as "Recommends" and leave the "Depends" for what we really mean as
> Depends.  Since there are the frequently discusses drawbacks and
> compatibility issues with the current tasks files this is nothing that
> should be done quickly.  So for the moment "post-processing" of the
> d/control file in the proposed manner should provide a quick (and
> hopefully not to dirty) solution.

Debian Edu mostly only uses the blends framework to create these meta
packages, (and since we frequently have had issues with that) so since 
some time I have been thinking whether if it wouldnt be better to just 
not use the frame work and just maintain debian/control manually…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: #793667: forced depends (instead of recommends) using blends-dev

[Petter Reinholdtsen]

[Andreas Tille]
> Since a long time I'm wondering whether we should craft tasks files to
> express what we "really" want (like specifying mostly all dependencies
> as "Recommends" and leave the "Depends" for what we really mean as
> Depends.  Since there are the frequently discusses drawbacks and
> compatibility issues with the current tasks files this is nothing that
> should be done quickly.  So for the moment "post-processing" of the
> d/control file in the proposed manner should provide a quick (and
> hopefully not to dirty) solution.

The tasksel description files have a "Key" concept, which if I remember
correctly is packages that must be available for the task to show up.
As such they behave a bit like depends for metapackages, where the
metapackage is uninstallable if some dependency is missing.

Perhaps we can introduce a Key: keyword in the blends task files and map
it to Key: in the tasksel description file and depends in the
metapackage?  It would avoid breaking existing blends tasks and give us
a way to enforce that a package is pulled in during upgrades.

It would also introduce a hard dependency between a package and the
task, exactly the kind of link we wanted to avoid when deciding to make
all task packages recommends or suggests, so it should be used with care
to avoid getting a task thrown out of testing needlessly when some nice
to have but not vital package is removed from testing.

-- 
Happy hacking
Petter Reinholdtsen

Re: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Andreas Tille]

Hi Holger,

On Mon, May 23, 2016 at 08:15:50AM +, Holger Levsen wrote:
> So we would like to force a depends on this gosa-plugin-netgroups
> package. How can we do that?

You can do this with the attached patch overriding the dist target to
afterwards change the d/control file.  Feel free to `git am` into the
repository.

Since a long time I'm wondering whether we should craft tasks files to
express what we "really" want (like specifying mostly all dependencies
as "Recommends" and leave the "Depends" for what we really mean as
Depends.  Since there are the frequently discusses drawbacks and
compatibility issues with the current tasks files this is nothing that
should be done quickly.  So for the moment "post-processing" of the
d/control file in the proposed manner should provide a quick (and
hopefully not to dirty) solution.

Kind regards

Andreas.

-- 
http://fam-tille.de
>From 790b24ed7bccc0569b0f7c36fc6d24a136951404 Mon Sep 17 00:00:00 2001
From: Andreas Tille 
Date: Tue, 24 May 2016 08:30:31 +0200
Subject: [PATCH] Hack in gosa-plugin-netgroups as Depends (workaround for
 #793667)

---
 Makefile | 8 
 1 file changed, 8 insertions(+)

diff --git a/Makefile b/Makefile
index 62935ca..996e987 100755
--- a/Makefile
+++ b/Makefile
@@ -1,3 +1,11 @@
 #!/usr/bin/make -f
 
 include /usr/share/blends-dev/Makefile
+
+dist:
+	rm -f $(BLEND)-tasks.desc debian/control
+	make -f debian/rules get-orig-source
+	sed -i -e '/^ *gosa-plugin-netgroups,$$/d' \
+	   -e '/^Package: education-main-server/{;N;N;N;N;s/\nDepends: [^\n]*/&, gosa-plugin-netgroups,/;}' \
+	   debian/control
+
-- 
2.8.1

#793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Holger Levsen]

Hi,

On Sun, May 22, 2016 at 06:30:39PM +, Mike Gabriel wrote:
> The relevant gosa-plugin* pks should go into Depends: of education-mainserver 
> task/bin:pkg. IMHO.

I'm not sure we can do this using the blends-dev package.

Background for the blends developers:

The debian-edu source package creates many education-* metapackages,
which recommend and suggest various other packages.

This used to work nicely, but #793667 shows that this causes problems on
upgrades, as new recommends are not installed, so the package 
gosa-plugin-netgroups is not pulled-in when upgrading from Debian Edu
mainserver…

So we would like to force a depends on this gosa-plugin-netgroups
package. How can we do that?


-- 
cheers,
Holger


signature.asc
Description: Digital signature