Brian Masinick
Like the original antix-base, isn’t this script intended for advanced users who will be comfortable with configuring their systems? If so, I don’t think it needs to do anything behind the scenes to configure things for the user. It really shouldn’t.
@anti-apXos this is precisely why I’ve been suggesting to keep this tool as simple as possible. Moreover, I suggested deciding what SHOULD be available in antiX Base, putting a list of those packages in a file, comparing it to the list of packages in antiX Full and simply install or remove packages based on one or both of those lists, end of story.
I suppose a more creative and complicated tool can be created to account for a few things, but the more you do that, the more complex it becomes, and unless the tool is heavily documented, it’s going to be complicated to replicate it or do this again later, whereas if a tool can be created strictly to install or remove packages based on one or two file lists, that’s pretty easy to do, and it’s also usable again – in that case, the only things that have to be altered between releases are those file lists.
I’ll be happy to try out the latest script from a live system so I can contribute to the testing, but I’ve also stated my position on this a couple of times, using someone different wording, but the same idea each time. I think this is a good code practicing exercise, but I already believe that the feature creep, refactoring, replacing, and trying has been repeated quite a few times already, when this job would be long since completed by comparing two lists of files – the full list and the desired reduced list, and use those two flat files to add, remove or alter what’s installed. I still think that method will survive the test of time.
--
Brian Masinick
Alternate "Search B":
This search page