Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop package acpi-support-base? #76

Open
mika opened this issue Apr 25, 2015 · 6 comments
Open

Drop package acpi-support-base? #76

mika opened this issue Apr 25, 2015 · 6 comments

Comments

@mika
Copy link
Member

mika commented Apr 25, 2015

acpi-support-base shouldn't be installed with systems running systemd according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783247 - we should think about dropping it from the default package list. I'm unsure yet though what to do about systems without systemd and how to handle that then. Maybe by supporting packages.$release or so?

@hartwork
Copy link
Contributor

hartwork commented May 6, 2015

packages.$release sounds like a plan.

@mika
Copy link
Member Author

mika commented May 8, 2015

Ok, we could start by copying the existing packages file to packages.{lenny,squeeze,wheezy} and then adjust for packages.jessie and packages.stretch. Then drop packages file overall and don't install /etc/debootstrap/packages any longer that way, only if the file exists then use it, otherwise default to /etc/debootstrap/packages.$release. This should ensure more flexibility with regards to target releases without breaking backwards compatibility for users customizing /etc/debootstrap/packages too much.

@hartwork
Copy link
Contributor

hartwork commented May 8, 2015

On users who customized /etc/debootstrap/packages, the only way to make sure they do not accidentally install machines with a config other than their custom packages (but with say packages.jessie) would be to

  • not ship packages any more and
  • quit with an error asking the user to rename/copy of packages to packages.${release}.

Personally, that's what I'd want as a user. What do you think?

@suntong
Copy link
Contributor

suntong commented Aug 11, 2019

I'm unsure yet though what to do about systems without systemd

I'd assume systemd will always be there, IMO, as long as it is still "in-the-trend".

This can "un-complicate" things a bit, again IMO.

@mika
Copy link
Member Author

mika commented Aug 11, 2019

systemd is present only in more recent Debian releases, and also isn't necessary/relevant when creating a container based system (where systemd wouldn't even really work).

More generic answer: we shouldn't try to manage a global package list that fits every single Debian/release, instead the list should be per release and it should be possible to easily remove/add packages on demand.

@suntong
Copy link
Contributor

suntong commented Aug 11, 2019

systemd is present only in more recent Debian releases...

Ah, thx for the explain.

the list should be per release

or, still keep a global package list that is the base for every single Debian/release, then per release based fine tuning (adding their own if necessary).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants