-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Reco wrote: > On Mon, Oct 07, 2019 at 01:08:04PM -0000, Dan Purgert wrote: >> Reco wrote: >>>> I don't think anything needs to be done here -- the whole idea of >>>> (meta)packages is that you give up some choice for the benefits of not >>>> having to deal with dependency hell. >>> >>> I disagree. The parent thread shows that at least some of the users are >>> confused by metapackages. >> >> So then the education needs to be fixed, not the material. I mean, at >> one point in our lives, we were all confused by what we'd consider >> "simple mathematics" nowadays. > > And we both know it does not work this way, although it should. > One could write thousand words in the documentation, explaining > everything in the finest detail possible. But if no one is reading the > documentation - is there a meaning in all this work? > > Hence my suggestion. Users are confused already, and it won't get > better. I have no problem filling a wishlist bugreport, but I like to > estimate the possible users' reaction.
The ultimate underlying problem is that in this case, the user didn't like that the package wanted to force a specific set of programs on the system. Now, yes, there are what sound like technical inconsistencies in the packages (i.e. they're not actually "required" by anything other than this metapackage itself); although it seems to be that the general user expectation would be that a DE supplies some form of archive handling capabilities. Whether or not that's extraneous to the user's preferred software is another question entirely -- I mean, I have cthulhu-knows how many different programs installed simply from core-utils. I probably touch but a fraction of them, and yet they're still here. Not to mention all the "extras" that come along with say groff, or LaTeX. >> [...] >> I think I worded the response here poorly. >> ... >> engrampa. Of those, I assume that all three provide the necessary >> "provides xyzzy" information (e.g. how installing postfix or exim >> "provides" /usr/sbin/sendmail) to allow generic graphical tools to hook >> ... > > No, I got you first time. Rather it's my response deviated elsewhere. > > I see nothing in those three packages that would qualify as "xyzzy". > Alternatives? No. Mime types registration? No. Certainly shows my limited understanding of how it all fits together, that's for sure :). > About the only common thing about all three packages is that they are > GUI archivers. > I do not question a choice of these three archivers as "lxqt" > dependency. What I do question is the kind of dependency itself. I might've deleted it in editing somewhere, I was operating under the assumption that "a gui archiver" is a required component of a "complete DE" (for some value of "complete", anyway). > > >> In either event, I think one of the mails mentioned wanting to use >> peaZip, which isn't even available in the repos, so it doesn't matter >> anyway; as APT would never be able to do dependency resolution. > > Why, apt certainly can do it. It's just requires the user to package > PeaZip first ☺ He's having a hard enough time with packages, that're already available in the repos. This is just mean :D -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl2bW1kACgkQjhHd8xJ5 ooHVbQf+NYtIWL4LMpk3GPENOaNmajaI6sVZwZ9x7llydHfxh+cDdPL5myLwBojd mAAbEBRvvafTE8WxEG7cBeqzQ/mNvW7LSa586kJfChJx32mnnAqU1Dkigal5n/69 JV6yRlV0BR6TrgiEQXsGRIbCkadOnA6GQBa0xSTzCL2DWGgK2Odk7ab4ESWUHZKc 4IqvRChJr9hBhl9R+li+R2PcJI91jgqXXzqMuEeAAE1h0Y+73phHxMqkF4otmfru kPBTNWYieOEfybuMigXkfIj9j0vb4bJffL6LHrDmi2+14YpmzImTIre3g9C7fjEh jfKyiOaSh4cVQb27OYd6iorieHZbFQ== =wH7V -----END PGP SIGNATURE----- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281