Re: f.el dependency loop (was: Re: Cask & dependencies)

[Paul Wise]

On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:

> 1) Use the nocheck build profile to build and upload f-el without
>running its tests.  Then build and upload shut-up and undercover.
>Then build and upload a full version of f-el.
>
> 2) Use the nocheck build profile to build and upload shut-up without
>running its tests.  Then build and upload f-el and undercover.
>Then build and upload a full version of shut-up.

I don't think you can upload binary packages using non-default build
profiles to the archive?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: f.el dependency loop (was: Re: Cask & dependencies)

[Jakub Wilk]

* Paul Wise , 2015-12-15, 18:43:

On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:

1) Use the nocheck build profile to build and upload f-el without 
running its tests.  Then build and upload shut-up and undercover. Then 
build and upload a full version of f-el.


2) Use the nocheck build profile to build and upload shut-up without 
running its tests.  Then build and upload f-el and undercover. Then 
build and upload a full version of shut-up.


I don't think you can upload binary packages using non-default build 
profiles to the archive?


You shouldn't upload them, but AFAICS dak wouldn't reject such an 
upload.


Perhaps we should add Lintian check for the Built-For-Profiles field, 
and ask ftp-masters to add the tag to the auto-reject list.


That said, the nocheck profile is supposed to have no effect on 
resulting binary packages, so probably uploading packages built with 
this profile activated wouldn't be a big deal...


--
Jakub Wilk

Re: f.el dependency loop (was: Re: Cask & dependencies)

[David Bremner]

Sean Whitton  writes:

>
> 3) Disable running f-el's test suite at package build time, but supply a
>autopkgtest so the tests will still get run in ci.debian.org.
>
> 4) Disable running undercover.el's test suite at package build time, but 
> supply a
>autopkgtest so the tests will still get run in ci.debian.org.
>
> What would be best?  Options (3) and (4) avoid introducing a new
> bootstrapping loop into the Debian archive.  But on the other hand maybe
> such a bootstrapping loop is okay because all these packages are
> architecture independent.

My initial opinion is to avoid a bootstrapping loop. That might be
partially because I've never really used build profiles before, but also
it seems to more or less double the number of sponsored uploads you'd
need.

d

Re: f.el dependency loop (was: Re: Cask & dependencies)

[Sean Whitton]

On Mon, Dec 14, 2015 at 09:04:00PM -0400, David Bremner wrote:
> My initial opinion is to avoid a bootstrapping loop. That might be
> partially because I've never really used build profiles before, but also
> it seems to more or less double the number of sponsored uploads you'd
> need.

I've dug a little deeper.  It turns out the circular chain of
dependencies are not actually required to run f's unit tests.  They are
only required for f.el's upstream continuous integration testing setup
(a setup not compatible with Debian CI, so far as I know).  I've been
able to use a quilt patch to scrub the dependency chain.

Sean


signature.asc
Description: Digital signature

f.el dependency loop (was: Re: Cask & dependencies)

[Sean Whitton]

Hello,

As I mentioned there's a dependency loop in building f-el [1].  This is
a library that a lot of Emacs addons depend on.  If we could get this
into the archive we would have dash-el, s-el and f-el all in Debian and
future dependency resolution would be much easier.

The problem is that f-el's test suite depends on undercover.el [2], which
depends on shut-up.el [3], but shut-up.el's test suite depends on f.el.

So far as I understand it, there are four options.

1) Use the nocheck build profile to build and upload f-el without
   running its tests.  Then build and upload shut-up and undercover.
   Then build and upload a full version of f-el.

2) Use the nocheck build profile to build and upload shut-up without
   running its tests.  Then build and upload f-el and undercover.
   Then build and upload a full version of shut-up.

3) Disable running f-el's test suite at package build time, but supply a
   autopkgtest so the tests will still get run in ci.debian.org.

4) Disable running undercover.el's test suite at package build time, but supply 
a
   autopkgtest so the tests will still get run in ci.debian.org.

What would be best?  Options (3) and (4) avoid introducing a new
bootstrapping loop into the Debian archive.  But on the other hand maybe
such a bootstrapping loop is okay because all these packages are
architecture independent.

Thanks.

Sean

[1] https://github.com/rejeep/f.el
[2] https://github.com/sviridov/undercover.el
[3] https://github.com/cask/shut-up


signature.asc
Description: Digital signature