Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.devel > #118107

Re: Building multiple flavors of a package with a HUGE upstream

From Marc Haber <mh+debian-devel@zugschlus.de>
Newsgroups linux.debian.devel
Subject Re: Building multiple flavors of a package with a HUGE upstream
Date 2025-07-25 20:20 +0200
Message-ID <Lcvbr-2Cgu-3@gated-at.bofh.it> (permalink)
References <L9ZIJ-XM9-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi,

I have solved the issue for me. I decided to stick to the most 
conservative approach of one fully fledged source package per kernel 
flavor and will solve the issue of wasted disk space on both the 
internal archive host and on the publicly visible download server with 
offline deduplication on the filesystem level. I think I will use btrfs 
on the internal archive host and XFS on the download server to get 
familiar with both methods, albeit similar. Zugschlus' leftover plate 
("Resterampe") of packages that noone wants will probably grow by one in 
this process as I have started the salvaging process for duperemove 
(which can thankfully both handle XFS and btrfs).

Of the suggestions I received the idea of having a 
linux-zugschlus-source binary package that the flavor packages could 
build-depend on the most enticing. I still decided to go a different way 
since I didn't have so much time to spend. I wrote a python program (> 
1000 lines *cough*) that builds the source packages using big parts of 
what upstream (and Wichert) have in scripts/packages, generating new 
stuff, including glue code to handle the kernel configuration files, 
updates, etc, and orchestrates the build of the four source packages and 
the respective binaries.

I decided against using Debian's src:linux because the packaging is WAY 
more complicated (and harder to understand) that I'll ever need, and I 
am usually faster in deploying new stable kernel releases than Debian 
is.

Build profiles I thankfully didn't need since the upstream packaging 
already fiddles around with the control file to control the creation of 
kernel headers, linux-libc6-dev and debug packages. It is an interesting 
concept but I'd rather take more time to understand it, and first use it 
the way it was intended to be used.

My original idea of having one orig.tar.gz for more than one source 
package wouldn't work because that use case is not supposed by 
dpkg-source: the orig.tar.gz always must have the same base name as the 
source package (even multiple source tarballs have to share the same 
prefix), hence I would need multiple, different, but identically named 
source packages which you can't put in an archive. That was a stupid 
idea of mine and I shouldn't have bothered you with that.

The most obvious but also time-consuming takeway was that you need to 
have ARCH and KBUILD_DEBARCH correctly set even for the 
{old,n,menu}config step or you will end up with a non-working kernel 
that will miss all parts specific to the target architecture when 
cross-building.

What I still don't really know is how to handle the linux-libc-dev 
package which doesn't have its name versioned and will therefore be 
built non-identically, but identically named, by every flavor, doubling 
the package name in the archive which doesn't make dak happy. I decided 
to only build that package from one of my flavors.

With the current results I can work for the time being. I might 
simplify the packaging at some future time (build profiles might 
actually help here, making the debian/rules way simpler than the one 
that comes with the kernel).

Thank you all for trying to help.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Back to linux.debian.devel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Building multiple flavors of a package with a HUGE upstream Marc Haber <mh+debian-devel@zugschlus.de> - 2025-07-18 22:20 +0200
  Re: Building multiple flavors of a package with a HUGE upstream Ahmad Khalifa <ahmad@khalifa.ws> - 2025-07-18 22:30 +0200
    Re: Building multiple flavors of a package with a HUGE upstream Ahmad Khalifa <ahmad@khalifa.ws> - 2025-07-18 22:50 +0200
    Re: Building multiple flavors of a package with a HUGE upstream Bastien Roucaries <rouca@debian.org> - 2025-07-18 23:50 +0200
  Re: Building multiple flavors of a package with a HUGE upstream Josh Triplett <josh@joshtriplett.org> - 2025-07-18 23:30 +0200
    Re: Building multiple flavors of a package with a HUGE upstream Marc Haber <mh+debian-devel@zugschlus.de> - 2025-07-18 23:50 +0200
  Re: Building multiple flavors of a package with a HUGE upstream Simon Richter <sjr@debian.org> - 2025-07-19 03:40 +0200
  Re: Building multiple flavors of a package with a HUGE upstream Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-07-19 21:30 +0200
    Re: Building multiple flavors of a package with a HUGE upstream Marc Haber <mh+debian-devel@zugschlus.de> - 2025-07-25 20:20 +0200
  Re: Building multiple flavors of a package with a HUGE upstream Ben Hutchings <ben@decadent.org.uk> - 2025-07-20 20:20 +0200
  Re: Building multiple flavors of a package with a HUGE upstream Marc Haber <mh+debian-devel@zugschlus.de> - 2025-07-25 20:20 +0200

csiph-web