Re: Extending the build profile namespace
Hi,
2016-04-25 19:06 Helmut Grohne:
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.
Reply to the above combined: I didn't mean to remove /all/ OPTIONS and
convert them to PROFILES (1st paragraph), but to merge them somehow when
they overlap or are the same (i.e., transition to profiles as in 2nd
paragraph), such as with "nocheck" and "nodoc*".
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 think that people building tailor-made systems will always have (or
want) to do manual work to... well, create a tailor made system. If you
want to make their life easier, that's fine.
From my perspective as porter (which is what I wanted to contribute),
for the purpose of bootstrapping new Debian architectures, the finer
detail is probably not necessary -- even if it could be nice to have.
Just being able to everything with as few interdependencies as possible
would be very nice, and then walk up from there enabling features as
necessary towards a "full" Debian system.
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.
IIRC it has bindings to other languages, depends on swig, go-related
packages... so one less to worry about.
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.
That doesn't fulfill the precondition of my statement above. If as part
of an automatic process the intermediate dep is rebuilt with the extra
feature (because e.g. by the 2nd/3rd/etc time that it's rebuilt it can
be built with the extra features needed for further phases), and then
lets the rdeps build fine and continue progress, all is fine.
In any case, having to rebuild by hand a few packages with extra
features is the least of one's worries when bootstrapping a new
architecture, compared all other requirements / efforts.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: