Comments by "Anony Mousse" (@anon_y_mousse) on "Linux Package Distribution Model Is Changing" video.

@supremespanker Top tier comedy. Have any more jokes?
7
My only two concerns would be security, like permission annoyance, and the look and feel of apps. As long as they respect my dark theme or have one built-in that's good, the look and feel I'm sure will be fine. The security features aren't always necessary, but as long as it's not too onerous I wouldn't care about that extra overhead.
4
The way I see it, we'll always need the base packages for a system to not be containerized or genericized. After the base system is setup, then we'll be good to go for pretty much anything. I just think that one of the things they need to do with packages is to not link to generic names but instead have fully qualified version numbers, or at least partially qualified. Such as not linking to libabc but instead libabc-1.2, presuming that anything to the right of minor revisions won't be API breaking changes. Obviously such infrastructure would require OS support of some kind, but if we can't even agree on an init system that's going to be hard to reconcile. Let's just hope they don't form a committee to explore the possible solutions.
3
@oro6768 Why so hostile? Are you a FlatPak developer?
3
@Poldovico Nope, still not solved. Plenty of people still get version conflicts. And plenty of people don't upgrade their system in a traditional manner as well, as in piecemeal.
2
@finoderi True, and there are a lot of projects that I've compiled from source just to use them because I'm on Slackware. Of course, that also means I can't use anything that's a FlatPak, something which hasn't bothered me enough to get it working yet, but may in the future if everyone shifts to that as the distribution method.
2
@Poldovico If you use a packaging system and nothing but, and if you update all at once, most will work fine. It's when something isn't available through your package management system that things break. And you may not always be able to cleanly resolve those issues. If you're a normal user, and not a seasoned developer, you're more likely to incur those issues and have no clue how to resolve them.
1
@Poldovico In other words, you have no sympathy for newbies. Stop making excuses, if someone either wants or needs a piece of software, and whether it's a want or a need is irrelevant, then they're going to blindly follow instructions online to get it installed. They won't know how to fix it and they won't know the correct terms to google to find instructions to do so. There's no amount of "but a packaging system fixes this or that type of problem" that's going to change that, and there's far more newbies than veteran users, especially now days.
1
@obake6290 In other words, it's not a solved problem. Not everyone can use FlatPak either, but again, installing things from source or from a third party will eventually cause problems. I'm struggling to put this in nice terms because the narrow-minded sociopathy on display from two different people is making me very angry. Not every user is a developer, especially now days, and nor should they have to be. Not every configure script can account for every configuration, and even when they account for it, the general method is to fail and prevent the user from compiling. Downgrading a dependency to get something to install is exactly the kind of thing a newbie would do and exactly the kind of thing that would break their system, and exactly the kind of situation they would have no clue how to fix. Try to see things outside of your own skull.
1
@obake6290 I'm not saying they shouldn't fail dishpit, I'm saying that the newbie user won't have a clue about why or how it could fail when they have a dependency and the versions don't match. Their method will nearly universally be to downgrade to meet the dependency and that will cause problems. If you don't understand that it's not just their problem but ours (and obviously I'm not including you in that, but our as in developers) to fix, then again I'm going to tell you to stop being a sociopath.
1
@jimmyneutron129 I'd argue that it's years-long development debt, project bloat. Eventually every piece of software will become its own OS, see Firefox and Emacs for examples of that in the extreme.
1
I think the easiest way to do that would be to not setup libraries through symlinks, or at the very least no bare symlinks where it's just the library name and no version number. If all your programs that use libabcxyz link to just abcxyz, then updating any one of them is going to give you a bad time, but if they link to main branches of API changes, say abcxyz-1.2.3 then updating would be a cinch. Even cooler still if the packager maintained a list of these dependencies and could allow you to save space by deleting dependencies you no longer need or even allowing you to update apps that are keeping them alive so you can delete them.
1