[Top][All Lists]

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

[task #15739] Wishlist - Debian patched stable or testing or unstable se

From: Boud Roukema
Subject: [task #15739] Wishlist - Debian patched stable or testing or unstable set of sources
Date: Sun, 2 Aug 2020 14:45:57 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Follow-up Comment #3, task #15739 (project reproduce):

[comment #1 comment #1:]

> By "download" software from Debian, you mean the source tarballs, right? In
particular, the "pristine-tar" branch of each package (like this one for
<>. You
don't mean downloading the binary packaged files, right?

I mean the source tarballs (_pristine-tar_) plus (at least) the debian
patches, e.g. or

It's the patches that represent a major part of the Debian quality assurance
pipeline in terms of fixing source code.

I definitely don't mean downloading the binaries - the Debian build system is
only run on 22 different systems currently (9 official, 13 unofficial).

There may be other steps in the build process - checking parameters in
_debian/control_ , for example, that we might also want to implement. The
_debian/rules_ file often gives security hardening steps for compilation. The
question for each step would be: is the advantage in reliability/security
worth the cost in needing more tools?

Applying the patches - in the recommended order!!! - would already, it seems
to me, implement a significant part of the benefit of Debian.

> If so, then your suggestion would translate to an interesting suggestion:
only updating versions of software that are in certain stages of the Debian
release (stable, testing or unstable). We can even write a small script to
parse the unified Debian interface and get the list of packages that need

Yes, that's definitely a good idea!

> Running this script can even be provided at configure time, so the person
running Maneage can say that for example, I want all my software versions
(with build instructions in Maneage!) to match the current Debian stable. That
script would then update the project's 'versions.conf' and 'checksums.conf'
source files and build those versions. Later, the user can commit the changes
made in these files to be able to reproduce their project's software
environment independent of future updates to the Debian stable, testing or
unstable branches.

Would we want to add "our" archival copies of e.g. the debian stable packages
in Zenodo/maneage? Or how long-term are the debian archives of _orig_ tarballs
and _patch_ lists?

I guess by "commit the changes", you mean to archive them in Zenodo/maneage?
My guess is that's probably reasonable. We could either choose to archive the
patched files as a "patched archive" - for simplicity - or in the original
debian format - for easier checking against the official debian versions.

> This would also greatly simplify the task of us Maneage maintainers (every
month, we would just have to check with Debian testing and update the packages
to versions that are now used there! Instead of manually going and changing
all the versions like what I did the other day! 

In terms of software security and reliability, this would seem a big
improvement to me. I know you have good software skills :), but it's hard to
believe that you really thoroughly checked all the updates to 20-30 or however
many packages you updated.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]