info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1011049: freetype: breaks architecture bootstrap by depending on librsvg2-dev
1 view
Skip to first unread message
Helmut Grohne
May 16, 2022, 1:30:04 AM5/16/22
to
Source: freetype
Version: 2.12.1+dfsg-1
Severity: important
User: hel...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian...@lists.debian.org
freetype participates in architecture bootstrap. As such, it must be
careful about its Build-Depends. It now added librsvg2-dev, which is
built from librsvg, which Build-Depends on rustc, which pulls llvm. This
totally breaks architecture cross bootstrap.
Beyond breaking practical architecture bootstrap, it also breaks
theoretical architecture bootstrap, because librsvg Build-Depends on
libfreetype-dev. This poses a cycle that cannot be solved.
As such, I request that you temporarily revert the librsvg2-dev
dependency. Given that this breaks bootstrap ci, I ask for urgency here.
If you lack time, I can offer NMUing it. As the udeb package is already
built without rsvg, the same should be applicable to the main package.
Then, we should cooperatively figure out a way to meet freetype's need.
It is a bit unclear to me why freetype needs rsvg. Can you shed some
light on that part?
Depending on the answer to that question, multiple options are
available:
* If it is only used for testing, it can be annotated <!nocheck> and is
thus removed from any bootstrap issues.
* Judging the changlog, it could be demos that need rsvg without having
the main library actually use rsvg. In that case, it would be easy to
hide freetype2-demos behind a build profile (say
pkg.freetype.nodemos) and conditionalize the dependency to that
profile.
* Possibly, the need is more unconditional and we need to solve the
loop in some other package.
At this time, a quick, temporary revert and coordination is needed.
Helmut
Version: 2.12.1+dfsg-1
Severity: important
User: hel...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian...@lists.debian.org
freetype participates in architecture bootstrap. As such, it must be
careful about its Build-Depends. It now added librsvg2-dev, which is
built from librsvg, which Build-Depends on rustc, which pulls llvm. This
totally breaks architecture cross bootstrap.
Beyond breaking practical architecture bootstrap, it also breaks
theoretical architecture bootstrap, because librsvg Build-Depends on
libfreetype-dev. This poses a cycle that cannot be solved.
As such, I request that you temporarily revert the librsvg2-dev
dependency. Given that this breaks bootstrap ci, I ask for urgency here.
If you lack time, I can offer NMUing it. As the udeb package is already
built without rsvg, the same should be applicable to the main package.
Then, we should cooperatively figure out a way to meet freetype's need.
It is a bit unclear to me why freetype needs rsvg. Can you shed some
light on that part?
Depending on the answer to that question, multiple options are
available:
* If it is only used for testing, it can be annotated <!nocheck> and is
thus removed from any bootstrap issues.
* Judging the changlog, it could be demos that need rsvg without having
the main library actually use rsvg. In that case, it would be easy to
hide freetype2-demos behind a build profile (say
pkg.freetype.nodemos) and conditionalize the dependency to that
profile.
* Possibly, the need is more unconditional and we need to solve the
loop in some other package.
At this time, a quick, temporary revert and coordination is needed.
Helmut
Helmut Grohne
Jan 11, 2023, 8:40:04 AM1/11/23
to
Hi Hugh,
On Wed, Jan 11, 2023 at 04:55:05PM +1100, Hugh McMaster wrote:
> I've added support for your suggested build profile
> (pkg.freetype.nodemos), since it's useful (and more efficient) to
> build without the demos at times.
Thank you. As far as I can see, this makes the stage1 build profile
obsolete. Would you mind removing any traces of stage1 from the
packaging? Anyone who would formerly need stage1 can now use
pkg.freetype.nodemos.
> I have not yet added Build-Depends: librsvg2-dev <!stage1
> !pkg.freetype.nodemos> to debian/control, as upstream is looking at
> supporting other lighter SVG libraries that have a much smaller
> dependency chain.
From my point of view, you can add librsvg2-dev at any time provided
that it is conditional to pkg.freetype.nodemos.
If you happen to use a different SVG library, it may turn out that
bootstrap does not need the profile (and instead builds that other
library). You may keep this profile even when bootstrap does not use it
anymore. Actually, that was the point of deprecating stage1 as a
profile: Making profiles useful outside of a bootstrap scope.
> I hope this helps. Please let me know if you have any concerns.
Thanks for reaching out and letting me know what to expect. That makes
dealing with eventual fallout much nicer.
Helmut
On Wed, Jan 11, 2023 at 04:55:05PM +1100, Hugh McMaster wrote:
> I've added support for your suggested build profile
> (pkg.freetype.nodemos), since it's useful (and more efficient) to
> build without the demos at times.
Thank you. As far as I can see, this makes the stage1 build profile
obsolete. Would you mind removing any traces of stage1 from the
packaging? Anyone who would formerly need stage1 can now use
pkg.freetype.nodemos.
> I have not yet added Build-Depends: librsvg2-dev <!stage1
> !pkg.freetype.nodemos> to debian/control, as upstream is looking at
> supporting other lighter SVG libraries that have a much smaller
> dependency chain.
From my point of view, you can add librsvg2-dev at any time provided
that it is conditional to pkg.freetype.nodemos.
If you happen to use a different SVG library, it may turn out that
bootstrap does not need the profile (and instead builds that other
library). You may keep this profile even when bootstrap does not use it
anymore. Actually, that was the point of deprecating stage1 as a
profile: Making profiles useful outside of a bootstrap scope.
> I hope this helps. Please let me know if you have any concerns.
Thanks for reaching out and letting me know what to expect. That makes
dealing with eventual fallout much nicer.
Helmut
Simon McVittie
Jan 12, 2023, 2:30:03 PM1/12/23
to
On Wed, 11 Jan 2023 at 16:55:05 +1100, Hugh McMaster wrote:
> I've added support for your suggested build profile
> (pkg.freetype.nodemos), since it's useful (and more efficient) to
> build without the demos at times.
If freetype2-demos does what its name suggests, then this might be
> I've added support for your suggested build profile
> (pkg.freetype.nodemos), since it's useful (and more efficient) to
> build without the demos at times.
in-scope for the non-package-specific build profile noinsttest ("Disable
binary packages consisting entirely of automated tests, manual tests,
example/demo programs and test tools"). The scope of noinsttest is a bit
wider than its name suggests, because "as-installed" automated tests
like gtk-4-tests and examples/demos/manual tests like gtk-4-examples
seem like they have quite a lot in common.
However, I see there are other packages that depend on freetype2-demos,
which makes it unclear to me whether freetype2-demos *only* contains
demos, or whether it also contains general-purpose utilities analogous to
the ones in libglib2.0-bin (which would be out-of-scope for noinsttest).
smcv
Helmut Grohne
Jan 17, 2023, 9:30:03 AM1/17/23
to
Hi,
On Tue, Jan 17, 2023 at 10:43:10PM +1100, Hugh McMaster wrote:
> freetype2-demos only contains programs used to test and showcase the
> FreeType 2 font engine. They aren't general-purpose utilities.
>
> Would this mean the binary package qualifies for the noinsttest build profile?
Like Simon, I also think that freetype2-demos is a corner case where it
is not clear whether noinsttest is a reasonable profile. Simon certainly
made a good argument in favour. My personal judgement thus far was that
it is on the other side of the border, but clearly this is a trade-off
and I may be wrong. Beyond what was argued, I think that we typically do
not expect any reverse dependencies on packages tagged <!noinsttest>
(other than autopkgtests). In this case, we have one reverse dependency
open-font-design-toolkit and one reverse recommends
check-all-the-things. That still makes it a corner case from my point of
view.
I'm fine with both noinsttest and a package-specific profile and leave
it up to you. There is no "wrong" outcome to this.
A minor argument in favour of noinsttest is that rebootstrap enables
this profile for all packages, so freetype need no special handling
here.
Helmut
On Tue, Jan 17, 2023 at 10:43:10PM +1100, Hugh McMaster wrote:
> freetype2-demos only contains programs used to test and showcase the
> FreeType 2 font engine. They aren't general-purpose utilities.
>
> Would this mean the binary package qualifies for the noinsttest build profile?
Like Simon, I also think that freetype2-demos is a corner case where it
is not clear whether noinsttest is a reasonable profile. Simon certainly
made a good argument in favour. My personal judgement thus far was that
it is on the other side of the border, but clearly this is a trade-off
and I may be wrong. Beyond what was argued, I think that we typically do
not expect any reverse dependencies on packages tagged <!noinsttest>
(other than autopkgtests). In this case, we have one reverse dependency
open-font-design-toolkit and one reverse recommends
check-all-the-things. That still makes it a corner case from my point of
view.
I'm fine with both noinsttest and a package-specific profile and leave
it up to you. There is no "wrong" outcome to this.
A minor argument in favour of noinsttest is that rebootstrap enables
this profile for all packages, so freetype need no special handling
here.
Helmut
0 new messages