Debian Template: /etc/apt/sources.list issues and proposed changes

[adrelanos]

Currently:

deb http://http.debian.net/debian jessie main contrib non-free
deb http://security.debian.org jessie/updates main
deb-src http://security.debian.org jessie/updates main

Proposed:

deb http://security.debian.org jessie/updates main contrib non-free
deb http://ftp.us.debian.org/debian jessie main contrib non-free

Reasons

• deb-src isn't useful for most users, just slows down "apt-get update". Only required for using "apt-get source".
• deb-src only for security repository, but not for the regular repository, is also bogus. Either both or none.
• deb http://security.debian.org jessie/updates missing contrib and non-free. Yes, it exists: http://security.debian.org/dists/stable/updates/contrib/binary-i386/Packages.gz

FYI, more comments, see Whonix's implementation:
https://github.com/Whonix/anon-apt-sources-list/blob/master/etc/apt/sources.list.d/debian.list

[mig5]

+1 for this, I had made the exact same changes to my Debian templates. It is vital to ensure contrib/non-free packages that might get installed, get future security updates if needed

[mig5]

+1 for this, I had made the exact same changes to my Debian templates. It is vital to ensure contrib/non-free packages that might get installed, get future security updates if needed

[marmarek]

Maybe its better to still have deb-src lines, but commented out?

Anyway, @nrgaway, can you fix this?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Maybe its better to still have deb-src lines, but commented out?

Anyway, @nrgaway, can you fix this?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[nrgaway]

On 19 July 2015 at 08:44, Marek Marczykowski-Górecki <
notifications@github.com> wrote:

Maybe its better to still have deb-src lines, but commented out?

Anyway, @nrgaway, can you fix this?

Yes. I will be working on some Debian tickets this week

[nrgaway]

On 19 July 2015 at 08:44, Marek Marczykowski-Górecki <
notifications@github.com> wrote:

Maybe its better to still have deb-src lines, but commented out?

Anyway, @nrgaway, can you fix this?

Yes. I will be working on some Debian tickets this week

[nrgaway]

Currently the template is setting the this.

Do you want this fixed for new templates that are built, or something that will modify an existing users templates sources.list file via an update. I was thinking it may not be too cool to be touching an existing sources.list file.

[nrgaway]

Currently the template is setting the this.

Do you want this fixed for new templates that are built, or something that will modify an existing users templates sources.list file via an update. I was thinking it may not be too cool to be touching an existing sources.list file.

[marmarek]

Can we just use default debian behaviour for config files? Namely
update the file if wasn't modified by the user.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Can we just use default debian behaviour for config files? Namely
update the file if wasn't modified by the user.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Do you want this fixed for new templates that are built, or something that will modify an existing users templates sources.list file via an update. I was thinking it may not be too cool to be touching an existing sources.list file.

Please no sed magic modifying config files. Just a fix for new templates. Template upgrades by apt (if you even plan this?) might be accompanied by documentation advising to manually do this.

Can we just use default debian behaviour for config files? Namely update the file if wasn't modified by the user.

Depends. Is that file managed by a package? Where is the code for creation of it?

Case already managed by a package:

If it was managed by a package, then the file would only be automatically updated, if it wasn't modified by the user. Otherwise in case of user modification, users would get a dpkg interactive conflict resolution dialog. (example)

Case not yet managed by a package but planned:

I am not sure what would happen if a package took over that file if it already existed. Would probably be detected as user modification. Could be dealt with using config-package-dev. Anyhow, I don't think that's a good idea.

---

I originally didn't want to mix this in here, but since it came up now... That's why Whonix uses /etc/apt/sources.list.d/debian.list rather than /etc/apt/sources.list and recommends to touch neither one. That's something I planned to suggest as follow up.

[adrelanos]

Do you want this fixed for new templates that are built, or something that will modify an existing users templates sources.list file via an update. I was thinking it may not be too cool to be touching an existing sources.list file.

Please no sed magic modifying config files. Just a fix for new templates. Template upgrades by apt (if you even plan this?) might be accompanied by documentation advising to manually do this.

Can we just use default debian behaviour for config files? Namely update the file if wasn't modified by the user.

Depends. Is that file managed by a package? Where is the code for creation of it?

Case already managed by a package:

If it was managed by a package, then the file would only be automatically updated, if it wasn't modified by the user. Otherwise in case of user modification, users would get a dpkg interactive conflict resolution dialog. (example)

Case not yet managed by a package but planned:

I am not sure what would happen if a package took over that file if it already existed. Would probably be detected as user modification. Could be dealt with using config-package-dev. Anyhow, I don't think that's a good idea.

---

I originally didn't want to mix this in here, but since it came up now... That's why Whonix uses /etc/apt/sources.list.d/debian.list rather than /etc/apt/sources.list and recommends to touch neither one. That's something I planned to suggest as follow up.

[adrelanos]

Marek Marczykowski-Górecki:

Maybe its better to still have deb-src lines, but commented out?

Yes.

Or the same file, implementation that Whonix is using. Includdes deb-src
comments. With minor comment adjustments (no kdesudo). I think Whonix's
implementation is good, because as far I remember, that solution has
never generated a clarification question nor issue.

[adrelanos]

Marek Marczykowski-Górecki:

Maybe its better to still have deb-src lines, but commented out?

Yes.

Or the same file, implementation that Whonix is using. Includdes deb-src
comments. With minor comment adjustments (no kdesudo). I think Whonix's
implementation is good, because as far I remember, that solution has
never generated a clarification question nor issue.

[adrelanos]

While you're at it, for /etc/apt/sources.list.d/qubes-q3.list please also out comment the deb-src line.

[adrelanos]

While you're at it, for /etc/apt/sources.list.d/qubes-q3.list please also out comment the deb-src line.

[adrelanos]

What's the status of this one?

[adrelanos]

What's the status of this one?

[marmarek]

Already implemented for new templates:
QubesOS/qubes-builder-debian@d79ee37
marmarek/qubes-core-agent-linux@d04e5b5

It wouldn't be fixed automatically in already installed templates. Should we care about it? This would probably require migrating with standard Debian entries to /etc/apt/sources.list.d/debian.list (instead of main sources.list), which would be owned by some package.

[marmarek]

Already implemented for new templates:
QubesOS/qubes-builder-debian@d79ee37
marmarek/qubes-core-agent-linux@d04e5b5

It wouldn't be fixed automatically in already installed templates. Should we care about it? This would probably require migrating with standard Debian entries to /etc/apt/sources.list.d/debian.list (instead of main sources.list), which would be owned by some package.

[adrelanos]

I would only mention this in in place upgrading documentation. Fixing this with a script seems fragile.

Migrating to /etc/apt/sources.list.d/debian.list can be considered.

Although something Whonix specific to consider with the name /etc/apt/sources.list.d/debian.list. That file name is shipped by https://github.com/Whonix/anon-apt-sources-list. So naming it the same way would break Whonix builds. I can and perhaps should rename the file in Whonix if you want. We then still would need to somehow make sure we don't have two of these files.

[adrelanos]

I would only mention this in in place upgrading documentation. Fixing this with a script seems fragile.

Migrating to /etc/apt/sources.list.d/debian.list can be considered.

Although something Whonix specific to consider with the name /etc/apt/sources.list.d/debian.list. That file name is shipped by https://github.com/Whonix/anon-apt-sources-list. So naming it the same way would break Whonix builds. I can and perhaps should rename the file in Whonix if you want. We then still would need to somehow make sure we don't have two of these files.

[marmarek]

The same applies to the current situation, no? Whonix provides
/etc/apt/sources.list.d/debian.list, while the same repositories are
already configured in /etc/apt/sources.list, I guess. How can fix
solve this?
Maybe we should split source list file (whatever it will be named) to
some subpackage, which will be removed in process of Whonix template
build? Is there anything Whonix-specific in
/etc/apt/sources.list.d/debian.list shipped with Whonix? Maybe we
could simply not install it there (in Qubes templates) and use already
existing repository configuration (shipped by some Qubes package, or
created in process of template build)?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

The same applies to the current situation, no? Whonix provides
/etc/apt/sources.list.d/debian.list, while the same repositories are
already configured in /etc/apt/sources.list, I guess. How can fix
solve this?
Maybe we should split source list file (whatever it will be named) to
some subpackage, which will be removed in process of Whonix template
build? Is there anything Whonix-specific in
/etc/apt/sources.list.d/debian.list shipped with Whonix? Maybe we
could simply not install it there (in Qubes templates) and use already
existing repository configuration (shipped by some Qubes package, or
created in process of template build)?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

One thing might speak against an apt sources list package:
You'll need a separate version of that package per suite (wheezy, jessie, stretch, sid, whatever you want to support).
What do you think?

Qubes and Whonix could even share the very same package.

The same applies to the current situation, no?

Yes and no. For now, the Qubes sources list file is not managed by dpkg. But if you switch to packaging that file, it will be managed by dpkg. And if then name it exactly as anon-apt-sources-list, that will cause issues. By default, only one package may ship one file. Not overwrite another package's file. Otherwise, dpkg will refuse to install it. dpkg, build error.

qubes-template-whonix keeps care of preventing duplicate sources, here:
https://github.com/nrgaway/qubes-template-whonix/blob/master/whonix-gateway/02_install_groups_pre.sh#L275-L278

(I fixed that comment: https://github.com/nrgaway/qubes-template-whonix/pull/2)

Is there anything Whonix-specific in /etc/apt/sources.list.d/debian.list shipped with Whonix?

No.

[adrelanos]

One thing might speak against an apt sources list package:
You'll need a separate version of that package per suite (wheezy, jessie, stretch, sid, whatever you want to support).
What do you think?

Qubes and Whonix could even share the very same package.

The same applies to the current situation, no?

Yes and no. For now, the Qubes sources list file is not managed by dpkg. But if you switch to packaging that file, it will be managed by dpkg. And if then name it exactly as anon-apt-sources-list, that will cause issues. By default, only one package may ship one file. Not overwrite another package's file. Otherwise, dpkg will refuse to install it. dpkg, build error.

qubes-template-whonix keeps care of preventing duplicate sources, here:
https://github.com/nrgaway/qubes-template-whonix/blob/master/whonix-gateway/02_install_groups_pre.sh#L275-L278

(I fixed that comment: https://github.com/nrgaway/qubes-template-whonix/pull/2)

Is there anything Whonix-specific in /etc/apt/sources.list.d/debian.list shipped with Whonix?

No.

[marmarek]

On Thu, Aug 06, 2015 at 02:32:19PM -0700, Patrick Schleizer wrote:

One thing might speak against an apt sources list package:
You'll need a separate version of that package per suite (wheezy, jessie, stretch, sid, whatever you want to support).
What do you think?

We already have this handled in qubes-core-agent:

sed -e "s/@DIST@/`lsb_release -cs`/" misc/qubes-r3.list.in > $(DESTDIR)/etc/apt/sources.list.d/qubes-r3.list

Anyway this probably means that we can't directly reuse
anon-apt-sources-list.

The more I think about it, the more I'm convinced that we should stay
with the current approach - sources.list manually created during
template build. This is how native debian is installed, right? So I
think we should stick with that way, not reinvent it.
What do you think?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Aug 06, 2015 at 02:32:19PM -0700, Patrick Schleizer wrote:

One thing might speak against an apt sources list package:
You'll need a separate version of that package per suite (wheezy, jessie, stretch, sid, whatever you want to support).
What do you think?

We already have this handled in qubes-core-agent:

sed -e "s/@DIST@/`lsb_release -cs`/" misc/qubes-r3.list.in > $(DESTDIR)/etc/apt/sources.list.d/qubes-r3.list

Anyway this probably means that we can't directly reuse
anon-apt-sources-list.

The more I think about it, the more I'm convinced that we should stay
with the current approach - sources.list manually created during
template build. This is how native debian is installed, right? So I
think we should stick with that way, not reinvent it.
What do you think?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

I concur.

[adrelanos]

I concur.