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

Re: Extending the build profile namespace

On Mon, Apr 25, 2016 at 01:28:00PM +0100, Manuel A. Fernandez Montecelo wrote:
> Perhaps these OPTIONS and PROFILES should be merged, in a way that if
> one is enabled, the other also is.  (Is this the plan already?)

They serve different needs. Quite a few options do not make sense as
profiles. What do you do with parallel=n? None of nocheck, noopt or
nostrip should change any package relations. noddebs changes which
packages are built, but those are not part of d/control anyway. Then
there is the non-standard but frequently used debug option.

> (Same applies for "nodoc*").

As Ian pointed out, it may still make sense to transition some options
to profiles.

> Even if for many packages it wouldn't be necessary to drop some/most
> functionality, the target for bootstrap builds should be IMO to only
> enable the minimal necessary deps for the packages to work (to save time
> and space when [re]bootstrapping, if nothing else).

I actually think that it should be possible to use the result of a
bootstrap as is. You see, that's exactly what Yocto, Buildroot, PTXdist,
and others do. Just Debian has much better security support, long term
support, package quality and quantity than any of the contenders.

> I'd consider also a "noaudit", it's a lot of rdeps and the use of this
> framework is not needed at the time of bootstrapping.

Yes. Obvious omission. It is not clear though whether bootstrapping with
or without audit is easier.

> However, in general as a part-time-porter, I don't think that
> distinguishing between safe and unsafe is important for the general case
> of bootstrapping and architecture (it's more important for the case of
> checking whether everything is bootstrappable).

It's crucial for an algorithm to be able to choose profiles. I want to
remove the need to have to think about which stages are necessary.

> The failure (or unsafeness) of packages to behave normally doesn't
> matter, as long as it eventually allows to reach a stage where your
> whole set can be used to rebuild and improve itself to a full-fledge
> Debian.

It matters as soon as your reverse dependencies fail to build. Spoiler:
They do occasionally.


Reply to: