Allow uninstalling inactive git versions
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- docker, typescript
Línea de trabajo
Start by reading GitInstallService and InstallToolService.uninstall, then inspect the version service check mentioned in the proposal and the existing uninstall tests. Add coverage for removing an inactive git version, refusing to remove the active one, and the chosen --all behavior. Done means inactive versions and their links can be removed while the active version remains protected with a clear message.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What would you like containerbase to do?
Allow uninstall-tool git <version> for versions that aren't the active one.
Background
git comes from the containerbase prebuild now (#7813), so every install-tool git <version> adds a version under the tools folder. GitInstallService sets canUninstall = false, so old versions can't be removed and pile up in images that switch versions.
Removing the active version must stay refused: it backs the git links, the /usr/bin compatibility links and the containerbase-git apt package.
Proposal
- Let a tool refuse only the uninstall of its active version (e.g. a
canUninstallmode or a check inInstallToolService.uninstallviaversionSvc.isCurrent), instead of refusing every version. - Use it for git: inactive versions are removed with their folder and links, the active one keeps failing with a clear message.
uninstall-tool git --allremoves every inactive version and keeps the active one, or fails before removing anything — pick one and document it.- Tests for both cases.
Drafted by Claude Opus 5.5 (Claude Code) for @viceice.
- Lenguaje dominante
- TypeScript
- Estrellas
- 58
- Forks
- 65
- Merge medio
- 10 h 37 min
- PR fusionados (30 d)
- 462
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de containerbase/base
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
containerbase/base#7891 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
containerbase/base#7842 ·
Los mantenedores suelen responder en 1 día
-
priority-3-normal tool/dotnet
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
containerbase/base#5996 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 65/100
containerbase/base#7971 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
containerbase/base#7970 ·
Los mantenedores suelen responder en 1 día
Todos los issues de containerbase/base
Issues similares
-
type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
Los mantenedores suelen responder en 1 día
-
0️⃣ phase/new
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
microsoft/playwright#43640 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100