Bug #15778

Make the Tails Installer upstream tarball DFSG-free

Added by intrigeri 2018-08-09 11:49:51 . Updated 2019-08-04 08:13:14 .

Status:
Confirmed
Priority:
Low
Assignee:
nodens
Category:
Installation
Target version:
Start date:
2018-08-09
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Installer
Deliverable for:

Description

Our release process for Tails Installer is complicated by the fact we repack the upstream tarball to remove the tools/ directory and in turn make it DFSG-free. I think the only reason why we’ve historically chosen to keep the Windows binaries in tools/* was: we might need them if we port the Installer to Windows (Feature #8550). But we have no such plan anymore, our plan is Feature #15292 which does not require to do that. So we could now delete the tools/ directory from our master Git branch and simplify the release process doc.


Subtasks


Related issues

Related to Tails - Feature #7036: Move custom software to our main Git repository In Progress

History

#1 Updated by intrigeri 2018-08-09 11:51:12

  • Description updated

#2 Updated by intrigeri 2018-08-09 14:08:48

  • Assignee changed from intrigeri to nodens

#3 Updated by Anonymous 2018-08-16 10:13:36

#4 Updated by intrigeri 2018-08-18 14:07:16

(Even with Feature #15292 we’ll keep Tails Installer in Tails, so simplifying its maintenance is still worth it.)

#5 Updated by intrigeri 2018-08-18 14:16:24

#6 Updated by sajolida 2019-07-22 17:11:56

Now that Tails Installer only lives in Tails, does it still make sense to talk about an “upstream tarball”?

#7 Updated by Anonymous 2019-07-23 08:53:57

sajolida wrote:
> Now that Tails Installer only lives in Tails, does it still make sense to talk about an “upstream tarball”?

Yes, it does. “Upstream” is the part of a (Debian) package that is the actual software. And the upstream authors regularly release an upstream tarball that is used to create the Debian package. The fact that in this case, upstream and packagers are the same people, does not matter in the naming.

#8 Updated by intrigeri 2019-08-04 08:05:24

  • related to Feature #7036: Move custom software to our main Git repository added

#9 Updated by intrigeri 2019-08-04 08:13:14

Hi!

u wrote:
> sajolida wrote:
>> Now that Tails Installer only lives in Tails, does it still make sense to talk about an “upstream tarball”?

> Yes, it does. “Upstream” is the part of a (Debian) package that is the actual software. And the upstream authors regularly release an upstream tarball that is used to create the Debian package. The fact that in this case, upstream and packagers are the same people, does not matter in the naming.

You’re (correctly) describing the current state of things. OTOH I understand that sajolida was essentially questioning whether that very current state of things still makes sense.

I would go further and rephrase the question this way:

  • What’s the value of maintaining a Tails Installer Debian package nowadays? (As opposed to installing it in the Tails image with something like python3 setup.py install, like we already do for our Python library)
    • Personally, I see very little such value and it’s clear to me that the overhead cost greatly outweighs it (it’s a PITA to work on these things).
  • If we stop maintaining a Tails Installer Debian package: what’s the value of maintaining Tails Installer in its own Git repo? (I’m asking because the FT is in the process of merging some other repos, such as Tails Greeter, into tails.git, to make our work more pleasant+efficient and to make it easier to onboard new contributors: Feature #7036. If there’s a particular reason why Tails Installer should not be subject to this treatment, please comment there :)