Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sat, 22 Mar 2014 23:48:06 + hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Alec Warner: > > https://wiki.gentoo.org/wiki/Package_Tags > > > > Object or forever hold your peace. > > > > Or argue for 100 posts, either way. > > Sounds good, but how do we get consistency in there? I mean... this > only works if we have some sort of consensus about tag names, at least > more common ones. By aggregating a global list of tag names; that way, when you tag a package you can look for tags on the global list that apply to it, and if it happens two different ways to name something were brought up you can also discuss it with one another. I don't think the inconsistency would become of a size to be concerned about; but yes, at the very least we need to watch out in the beginning to not let it happen... Though, choosing the right tag naming early on might be a need for this to succeed; maybe we can brainstorm some examples of how packages would be tagged, to get an idea about it. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner wrote: > https://wiki.gentoo.org/wiki/Package_Tags > > Object or forever hold your peace. > > Or argue for 100 posts, either way. A possible problem with this would be whether much maintainers would be concerned enough to spend their time on this. By spending time thinking up with tags you give to a package, you lose some time working on a bug. Adding some quick tags one can think of does "something" when you're busy; but I'm not sure if limited time would yield a good set of tags. Crowdsourcing, as brought forward[1] by rich0, could yield a far more rich set of tags; together with a small bit of moderation for quality. [1]: http://article.gmane.org/gmane.linux.gentoo.devel/90693 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
Alec Warner dixit: > https://wiki.gentoo.org/wiki/Package_Tags Without expecting to have any weight on the discussion, I just wanted to let you know: As a system maintainer I like to use the categories, e.g. when doing 'eix -I media-fonts/' or in package.use 'media-fonts/* X'.
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sun, 23 Mar 2014 00:04:08 + hasufell wrote: > Ciaran McCreesh: > > On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner > > wrote: > >> https://wiki.gentoo.org/wiki/Package_Tags > > > > And do what with them? Right now this is a solution without a > > problem. > > > > Finding packages. Descriptions are not consistent, categories too > generic. Please explain, with examples, how tags will help with this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ciaran McCreesh: > On Sun, 23 Mar 2014 00:04:08 + hasufell > wrote: >> Ciaran McCreesh: >>> On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner >>> wrote: https://wiki.gentoo.org/wiki/Package_Tags >>> >>> And do what with them? Right now this is a solution without a >>> problem. >>> >> >> Finding packages. Descriptions are not consistent, categories >> too generic. > > Please explain, with examples, how tags will help with this. > When thinking about games, it is pretty obvious and common practice on almost any gaming platform/service like steam. You can't just say "this game is an rpg"... it may be a mix of genres. Tags may even identify features like "multiplay". USE flags cannot deliver that, because there is no "multiplay" or "3rd-person" flag for obvious reasons. Descriptions try to be short and and give an idea what the game is about, not list all the possible genres or common search terms. It also works the other way around. There are a lot of applications that are scattered across multiple categories like terminal emulators or file managers. The user ends up searching the web or wiki instead of using portage tools which would be far more efficient. so we have: * tags to extend categories, e.g. when a package might fit in more than one * tags to group similar packages which are scattered across multiple categories * tags for features or attributes that cannot be expressed by USE flags and cannot be guaranteed to be part of the description * and so on -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTLtt8XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgn3QP/0KLFi6Zdv/OkdwMi05gXqlr NHnHAPf2v83gTeAikBaXRq+P11wWzraUPMrQBNe6agU2VmQGpJTt97KrVzzXJAuQ ND1W2Dne6wV/c61UY/KDnGExb9QSXi6ow5eNZoJjoX1sUEorXaNDlI57sYaywlny auT45Vhp87jwJLFydM4dGK4girbqSPR145bLumdB1fj5PGKc9z3e8MT2MQ+4UgYo m4VGWxoJ//j6TX6Wv5zk0WJRPVoRdOqcTcficp90Km56d+eDV9Ijx5K0ZIQ46+7z zj0xZvCLGKYsELgQlXHrCHrhYH12xkyo54WzVP2SpLN7AldKs73qr+Ntst3cLxUw HL7inMHzRJoGsGbuYVXPzfOyDC23LDaofJrMjdny/vrUfA/I+Iu6NgAjAcy59QaC QtW/DIpoZtosHSz6Bh4UG89a/KwhgVzPyJ2C/On0FtOv6oJmGjuCRj3SfH1hM5s8 6D3DYxXDFjfJR8WPrnTpwyMDaPgMP1Aow+WowEHFnp9ApBa8at1QONJm020SBZZx f7vSi6Iu6C34kg6dzojuVQoSoP/wpzWDksh9hNRhrZnsefpjZRCN5cCjMqMI30ua ZTU7vVG1BAeUjB18EzPIccLrk/2Tv8QDYvIRnNHsFWdedOQK7t5cbIo9tmIpYmNb ucdX2RTAXEoxjN/dCgIV =SPv7 -END PGP SIGNATURE-
[gentoo-dev] Re: RFC GLEP 1005: Package Tags
Ciaran McCreesh posted on Sun, 23 Mar 2014 12:02:58 + as excerpted: > On Sun, 23 Mar 2014 00:04:08 + hasufell wrote: >> Ciaran McCreesh: >> > On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner >> > wrote: >> >> https://wiki.gentoo.org/wiki/Package_Tags >> > >> > And do what with them? Right now this is a solution without a >> > problem. >> > >> > >> Finding packages. Descriptions are not consistent, categories too >> generic. > > Please explain, with examples, how tags will help with this. One classic example in such discussions is kde's kmail and gnome's evolution. A package can have only one category so for these, the packager must choose either the appropriate DE category (as with kde-base/kmail) and leave it unlisted in the appropriate functionality category (mail-client), or alternatively, choose the appropriate functionality category (as with mail-client/evolution), and leave it unlisted under the appropriate DE (gnome-base I guess it'd be, since the evolution modules are in gnome-extra). But that limitation goes away with tags as a package could have as many tags as people found appropriate, so whatever category the packager chooses, it could have both tags and thus be discoverable in either spot. That does imply that at least one set of tags would correspond roughly to categories, tho a single kde tag for example, vs kde-base and kde-misc, would arguably suffice. But tags wouldn't need to be limited to categories... The glep should probably be expanded with several examples like that. (Tho don't construe this to say that I'm in favor of the idea. I'm neutral in general tho slightly negative as I think there are better ways to spend one's time, but gentoo is volunteers, and volunteers spend more time when they're motivated, so it's not a zero-sum game and if enough people are interested enough to drive it forward, go for it!) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Last rites: app-emacs/gnuserv-programs
# Ulrich Müller (23 Mar 2014) # Reintegrated into app-emacs/gnuserv. # See bug 177936, comment #9 and following for details. # Masked for removal in 30 days, bug 505432. app-emacs/gnuserv-programs pgplo3cDkgK8c.pgp Description: PGP signature
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner wrote: > https://wiki.gentoo.org/wiki/Package_Tags "This GLEP author would love to blight categories out of gentoo history as a giant mistake." Why? jer
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/03/14 15:46, Jeroen Roovers wrote: > "This GLEP author would love to blight categories out of gentoo > history as a giant mistake." It does not matter. Just remove that line. It is irrelevant. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMu98oACgkQRtClrXBQc7VElwD/Siuqz64ggZ23xZ7904sbgcrG Hkjp62BFzo8/LW5aHhMBAKiME3FuPuY+Ev4o5o/2j5QsKasHjPh0vuiCcHGoTY+N =pPnG -END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman wrote: > On Sat, 22 Mar 2014 23:48:06 + > hasufell wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Alec Warner: > > > https://wiki.gentoo.org/wiki/Package_Tags > > > > > > Object or forever hold your peace. > > > > > > Or argue for 100 posts, either way. > > > > Sounds good, but how do we get consistency in there? I mean... this > > only works if we have some sort of consensus about tag names, at least > > more common ones. > > By aggregating a global list of tag names; that way, when you tag a > package you can look for tags on the global list that apply to it, and > if it happens two different ways to name something were brought up you > can also discuss it with one another. I don't think the inconsistency > would become of a size to be concerned about; but yes, at the very > least we need to watch out in the beginning to not let it happen... > > Though, choosing the right tag naming early on might be a need for > this to succeed; maybe we can brainstorm some examples of how packages > would be tagged, to get an idea about it. > This is basically the same problem with USE flags. Personally I also dislike global USE flags on multiple levels, so I'm not entirely interested in tag consistency. That being said, I wouldn't object to such a feature very strongly. I don't consider it a blocker to GLEP adoption, merely a concern that we can address later. -A > > -- > With kind regards, > > Tom Wijsman (TomWij) > Gentoo Developer > > E-mail address : tom...@gentoo.org > GPG Public Key : 6D34E57D > GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D > >
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sun, Mar 23, 2014 at 2:57 AM, Tom Wijsman wrote: > On Sat, 22 Mar 2014 15:33:27 -0700 > Alec Warner wrote: > > > https://wiki.gentoo.org/wiki/Package_Tags > > > > Object or forever hold your peace. > > > > Or argue for 100 posts, either way. > > A possible problem with this would be whether much maintainers would be > concerned enough to spend their time on this. By spending time thinking > up with tags you give to a package, you lose some time working on a bug. > > Adding some quick tags one can think of does "something" when you're > busy; but I'm not sure if limited time would yield a good set of tags. > > Crowdsourcing, as brought forward[1] by rich0, could yield a far more > rich set of tags; together with a small bit of moderation for quality. > > Crowdsourcing poses its own set of problems, most of which I'm not eager to design software around. I'd rather deploy the GLEP, wait 6 months, see if it failed, and if so, do something else (or nothing else, and simply repeal it.) -A > [1]: http://article.gmane.org/gmane.linux.gentoo.devel/90693 > > -- > With kind regards, > > Tom Wijsman (TomWij) > Gentoo Developer > > E-mail address : tom...@gentoo.org > GPG Public Key : 6D34E57D > GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D > >
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alec Warner: > On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman > wrote: so I'm not entirely interested in tag consistency What are they for then if I cannot efficiently use them to search for software? (which I cannot, if there is no consistency) -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTLzRjXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAg0QMP/jhl0WmdDqDLB38uK1+G5Q8R Q5KhfDPikq0oeVRsxRIa37MQkVpDKzawKPYc1ITOAZ5P2vVRGTe+QiB7R/Ul8r2j 253o5gDZn17zsi7koHrF2T+XgDhT4OEJExVH49GT7XEvpxtXIl7y4T22dlghD2H4 nzLyJExW1eAao7TAAV2SVCiUskW8Ex07ei1yAYBodxcAHV4W8M74aZ6KiB81vYhm SxnXiQfKHYwzE7aQMMd5yefmDFA34OCH1PDXXI7PNtKUW1u771cmg/RuHVp4Ekdp badVqbKU5SrnPocg78hQRSpJSBPkI1N96v8Le1FDfjU0q+Q+G9a8ml+KkybQORFR CN+fU7yO9bs/r+/wb3Jzicn2LqFbLXX7j66NBuzUBVxHACBSyeqMi4yK58ZPi/rg LjxZ1wqb7zfW710DSICwUJyNrufQBgbzl4T0OtJPN45oE5HW8POXX2JZeIWiZLcF O3GdnZ/gkWcbVOGHjjAAWRiBkI7uReDsGL34nbOcVj1fZFh4fp1CUhIG1N1v3GNe 8MZY73zopE8wMRb+27H9ZTMt/jlDcpshJZ5mjrOkRTI8yjYxIFeBVokO6yUSEktg aBlPwhtMjlQ0KdUO2o86BAK26/BaguLhN8MCHimZbU5DOA6fp1P7lOqVg5Qzzn7k uGtRoAylQi13O2kXSOLW =/mYw -END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 hasufell: > Alec Warner: >> On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman >> wrote: so I'm not entirely interested in tag consistency > > What are they for then if I cannot efficiently use them to search > for software? (which I cannot, if there is no consistency) > > That said... if it's not about search terms, but rather about listing all tags of a single package, then it's pretty useless and people should rather use "longdescription". -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTLzVoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgmAsP/18uMwgHRtEdMHyHAITvUFO+ 1O1orSM78BUEfEQrXozD+OJ4BnOFChBTY2ue1BlVRB7l39HV4BfQwXtYLJl6oisG w4tJestVsSPsPDm1ke3zPqXzGk0QN+jsv/MnZQd/EyKyEh97icewKVifYFuQe1Ta fVhxHDLKIM0GJRsWnhrv6z06kMEVvUZcOg0wq6TysPx3YKe/2igG9aApNJdndxbK 1SNRNwkEzuHiuMZpwGuiyFFU7J0Q3YSl2yf4BLU9wxgD7K8XDoAF495EZovo2XhU /Mua/RqOXLFMF/Axr82j+WPpUKtXREHl1JiVRytYC0iHhcyiHLhmv6TaOW01odPK BsMxP4NIKfIIhWk+WadXNgFmop42Nd/g+5N8b3BcHloDetSJRPVxOL6N/KAPQEXR x+J29XVXX+GE8pnNDJlvS930/I5dyabDKrQJwmh4eWZChFTjD+5lfndjWF4YHMvj bN6kGibBfI6EQ6VqUJZ6LRgC1NYzFqeH4scR1kn4WT6DoSJw1O0KviZ8i2imr3+5 Ey1UtTZY8g+Npcv6oU1yCbqqhcudQqLSq01b9Lp/yNWVfRShpl8TshGcqcCtstEh 5FJLghXUNoucHMSUWlIcDSkXWQdlMddG4AWFs33gQAqC942FbaWKObfJV05rwXuN T2IysJBrXVb7ZDsCrsz8 =PYYp -END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
Dnia 2014-03-22, o godz. 15:33:27 Alec Warner napisał(a): > https://wiki.gentoo.org/wiki/Package_Tags > > Object or forever hold your peace. Honestly, I don't think metadata.xml is a good place for it. While I like the consistency with general use of that file, I feel like it's going to make the application of tags more cumbersome, more noisy and make it harder to maintain consistency. As I see it, tags are not the same kind of package property as the description or package name. As I see it, current metadata.xml properties are somehow constant. They are usually set by the maintainer, do not change often and are strictly related only to the package. Tags, on the other hand, are more 'live'. They place the package somewhere in the 'global' tag hierarchy that can change over time. I expect that people other than maintainers will be adding tags to packages (and changing them), and that people will invent new tags and apply them to more packages. So, first of all, your solution would mean that every commit adding a new tag or changing one of the tags would modify the package metadata.xml. This means a Manifest update and a ChangeLog entry (please don't get into more rules for ChangeLogs now), and this means it will be harder to find actually useful entries there. So we make tag updates harder, and increase time and size of rsync. Secondly, since tags for every package will be held in different files, people will need dedicated tools to collect tags from all those files and add matching tags to their own packages. Long story short, we're going to have many 'duplicate' tags that will require even more commits with ChangeLog entries and Manifest updates. Worse than that, your GLEP doesn't even have any basic rules for naming tags -- like what language form to use and, say, which character to use instead of space. This sounds like the sort of things that's going to make it even harder to get some consistency, especially if some developers are going to follow someone else committing earlier and some will follow their own rules. I'd honestly prefer that -- if we should really keep tags in the tree -- to do that with a single 'metadata/tags' file or some kind of hierarchy there. Keep them outside the package directory -- bind packages to tags, rather than tags to packages. Keep all the commits in a single place without altering the ebuild work flow. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: > Dnia 2014-03-22, o godz. 15:33:27 Alec Warner > napisał(a): > >> https://wiki.gentoo.org/wiki/Package_Tags >> >> Object or forever hold your peace. > > > I'd honestly prefer that -- if we should really keep tags in the > tree -- to do that with a single 'metadata/tags' file or some kind > of hierarchy there. Keep them outside the package directory -- > bind packages to tags, rather than tags to packages. Keep all the > commits in a single place without altering the ebuild work flow. > That sounds better. That way it is also easier to get some consistency. E.g. tags can be discussed... but adding packages to tags is up to the maintainers. The GLEP should maybe cover a basic set of tags. Then projects like games, science etc could add their sets as well which may be a bit more specific... instead of random maintainers adding random tags. -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTLz8xXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgYpsP/ip5e4Jf1WmU3ThkQmLTu8p2 j67H8RNciPIrxnhhqCtl86mVVsBYKnMA1jwQI/5Yu1aqXnjTM+mEpwbWmas79vm5 0Djam0584DUDCcxkQPUFBs0qmxcWKzQOtClONPWbdgRryKS0csBoDhrJX1JtA3aQ Cn5Nj1psgaMlS/YeezQI1IVnIJIHaSuJ5v4AQZCwKofuMAeQvhFa3WaZVMcApJxj ARABa4ZQ3kt7baL0J9/L9vmMbGZ0mWb0K0qGZ9kqhkUtRIgC2fhXad1haIHlcyGB diXh5UyJgwHKuYKJ1OcmsVHc1EtueJUWCWoRsOQduRfcHahdRhkRh0+zk3HW6hq2 5m+GMrYzFkBBYcfZmFpCK2ElYQ4Pk4rncagLavry7THY/7+8MlTNhdGKMTHo99nk M5WzcZI1S24sY5h/vZHIkpx2IS+gZE5+9FpJ2H76uu+hk7vU8t2owjZcret1FbZ9 sM4DgmSjDkMWNWDBVlyIiCDoT0VKFEG+8rNa1o9msnrbpyIu7xHHNcgPG5Xvx2Rk ebatg8mq/qPQMEFOwICej72q1AbeXZcEPxKuL13g5RcDAHMjlPfL0pzN8g341+i+ UepHoU/RK30sd+Kp+NsLIS+RKesuujNS7DQa8FOtr8GuP0sAo4BdV+syT6avKK8A ixYiHLmcm4Y1eTdV6e20 =Q5/K -END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 03/23/2014 15:44, Michał Górny wrote: > Dnia 2014-03-22, o godz. 15:33:27 > Alec Warner napisał(a): > >> https://wiki.gentoo.org/wiki/Package_Tags >> >> Object or forever hold your peace. > > Honestly, I don't think metadata.xml is a good place for it. While I > like the consistency with general use of that file, I feel like it's > going to make the application of tags more cumbersome, more noisy > and make it harder to maintain consistency. > > As I see it, tags are not the same kind of package property > as the description or package name. As I see it, current metadata.xml > properties are somehow constant. They are usually set > by the maintainer, do not change often and are strictly related only to > the package. IMHO, metadata.xml is actually the best place to describe a package with tags, but I am not so sure it's the best place to "define" a tag. I guess if we automate the indexing of tags, much like how use.desc.local is generated from metadata.xml, then that might eliminate some of the maintenance overhead. The only way tags are going to work well is to keep the management of them as automated as possible. They should only be involved in searches for packages, and nothing else. E.g., hypothetical emerge command might be: emerge -T mail,client, which will show me all packages with the tag of 'mail' and 'client' (I didn't check emerge to see if -T already has a purpose, btw). And I think we should limit the number of tags allowed per package to a reasonable number. Maybe five tags maximum? StackOverflow is one example where they restrict questions to five tags. In addition, SO tries to suggest to you already-existing tags so that you reuse them instead of creating new ones all the time. Repoman could be extended to issue a warning when metadata.xml contains previously undefined tags and optionally display a match of similarly-named, existing tags (if only to catch misspellings, 'mial' or 'cleint' instead of 'mail' and 'client'). > Tags, on the other hand, are more 'live'. They place the package > somewhere in the 'global' tag hierarchy that can change over time. > I expect that people other than maintainers will be adding tags to > packages (and changing them), and that people will invent new tags > and apply them to more packages. > > So, first of all, your solution would mean that every commit adding > a new tag or changing one of the tags would modify the package > metadata.xml. This means a Manifest update and a ChangeLog entry (please > don't get into more rules for ChangeLogs now), and this means it will be > harder to find actually useful entries there. > > So we make tag updates harder, and increase time and size of rsync. Instead of individual lines in metadata.xml for each tag, why not a single line that contains a comma-delimited list of up to five tags, whitespace optional? That should help reduce the "fluff" of the tree by adding this feature. E.g., one,two,three,four,five vs. one two three four five (36 bytes vs. 82 bytes) > Secondly, since tags for every package will be held in different files, > people will need dedicated tools to collect tags from all those files > and add matching tags to their own packages. Long story short, we're > going to have many 'duplicate' tags that will require even more commits > with ChangeLog entries and Manifest updates. If we automate the generation of a master tag index file, like use.desc.local, this can be avoided. emerge can simply go rummage through the master index for matching tag entries instead of going through the entire tree. Because if we wanted to sift through the entire tree, grep would be a far better method (compiled C and probably better text-matching algorithms than emerge). > Worse than that, your GLEP doesn't even have any basic rules for naming > tags -- like what language form to use and, say, which character to use > instead of space. This sounds like the sort of things that's going to > make it even harder to get some consistency, especially if some > developers are going to follow someone else committing earlier and some > will follow their own rules. Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no spaces. A lot of problems are avoided if we keep tags to one-word descriptors only. E.g., for mail clients, they would carry both 'mail' and 'client' as two of their five tags. For kmail, a third tag would be 'kde' and Evolution would have 'gnome' instead. > I'd honestly prefer that -- if we should really keep tags in the tree > -- to do that with a single 'metadata/tags' file or some kind of > hierarchy there. Keep them outside the package directory -- bind > packages to tags, rather than tags to packages. Keep all the commits > in a single place without altering the ebuild work flow. While I definitely like the idea of a single, master file, I feel this could run away pretty quickly as it's continuously updated. For example, adding a new package, a dev has to now
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
Dnia 2014-03-23, o godz. 16:27:43 Joshua Kinard napisał(a): > On 03/23/2014 15:44, Michał Górny wrote: > > Tags, on the other hand, are more 'live'. They place the package > > somewhere in the 'global' tag hierarchy that can change over time. > > I expect that people other than maintainers will be adding tags to > > packages (and changing them), and that people will invent new tags > > and apply them to more packages. > > > > So, first of all, your solution would mean that every commit adding > > a new tag or changing one of the tags would modify the package > > metadata.xml. This means a Manifest update and a ChangeLog entry (please > > don't get into more rules for ChangeLogs now), and this means it will be > > harder to find actually useful entries there. > > > > So we make tag updates harder, and increase time and size of rsync. > > Instead of individual lines in metadata.xml for each tag, why not a > single line that contains a comma-delimited list of up to five tags, > whitespace optional? That should help reduce the "fluff" of the tree by > adding this feature. > > E.g., > > one,two,three,four,five Either use XML, or don't use XML. Don't make this some kind of ugly mixture of XML with non-XML. So: one two if we're really going for this. But I guess our DTD doesn't allow easy definition of single with no forced position. > > Secondly, since tags for every package will be held in different files, > > people will need dedicated tools to collect tags from all those files > > and add matching tags to their own packages. Long story short, we're > > going to have many 'duplicate' tags that will require even more commits > > with ChangeLog entries and Manifest updates. > > If we automate the generation of a master tag index file, like > use.desc.local, this can be avoided. emerge can simply go rummage through > the master index for matching tag entries instead of going through the > entire tree. Because if we wanted to sift through the entire tree, grep > would be a far better method (compiled C and probably better text-matching > algorithms than emerge). And this goes pretty much backwards to what we were aiming at. We should finally kill use.desc.local, not get inspired by the redundancy. > > Worse than that, your GLEP doesn't even have any basic rules for naming > > tags -- like what language form to use and, say, which character to use > > instead of space. This sounds like the sort of things that's going to > > make it even harder to get some consistency, especially if some > > developers are going to follow someone else committing earlier and some > > will follow their own rules. > > Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no > spaces. A lot of problems are avoided if we keep tags to one-word > descriptors only. E.g., for mail clients, they would carry both 'mail' and > 'client' as two of their five tags. For kmail, a third tag would be 'kde' > and Evolution would have 'gnome' instead. I'm pretty sure you will finally hit something that goes with two words. Protocol name or something. > I'd also suggest that 'all' be considered a default, global tag for all > packages, it be a reserved tag internal to emerge and other package > managers, and not count against the number of allowed tags (meaning that > technically, a package is allow five tags + 'all'). > > As for default tags when a package does not define any, the package category > gets split at the hyphen and becomes two independent tags. This is > overridden when at least one tag is defined in metadata.xml. Will this have a real benefit? Sounds like unnecessary confusion for a minor gain to me. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 03/23/2014 17:05, Michał Górny wrote: > Dnia 2014-03-23, o godz. 16:27:43 > Joshua Kinard napisał(a): > >> On 03/23/2014 15:44, Michał Górny wrote: >>> Tags, on the other hand, are more 'live'. They place the package >>> somewhere in the 'global' tag hierarchy that can change over time. >>> I expect that people other than maintainers will be adding tags to >>> packages (and changing them), and that people will invent new tags >>> and apply them to more packages. >>> >>> So, first of all, your solution would mean that every commit adding >>> a new tag or changing one of the tags would modify the package >>> metadata.xml. This means a Manifest update and a ChangeLog entry (please >>> don't get into more rules for ChangeLogs now), and this means it will be >>> harder to find actually useful entries there. >>> >>> So we make tag updates harder, and increase time and size of rsync. >> >> Instead of individual lines in metadata.xml for each tag, why not a >> single line that contains a comma-delimited list of up to five tags, >> whitespace optional? That should help reduce the "fluff" of the tree by >> adding this feature. >> >> E.g., >> >> one,two,three,four,five > > Either use XML, or don't use XML. Don't make this some kind of ugly > mixture of XML with non-XML. > > So: > > > one > two > > > if we're really going for this. But I guess our DTD doesn't allow easy > definition of single with no forced position. TBH, I don't like the use of XML at all. Never have and never will. I am a big fan of INI-style definitions (i.e., like Samba's config). XML just leads to a lot of unneeded fluff in what should be a really small file, which is why I was proposing a single element instead of multiple elements. E.g., instead for local USE of this: FOO BAR BAZ (96 bytes) This would be better: [local use] foo = "FOO" bar = "BAR" baz = "BAZ" (47 bytes) Not a complicated example, but would be >50% reduction in size. But, I digress... >>> Secondly, since tags for every package will be held in different files, >>> people will need dedicated tools to collect tags from all those files >>> and add matching tags to their own packages. Long story short, we're >>> going to have many 'duplicate' tags that will require even more commits >>> with ChangeLog entries and Manifest updates. >> >> If we automate the generation of a master tag index file, like >> use.desc.local, this can be avoided. emerge can simply go rummage through >> the master index for matching tag entries instead of going through the >> entire tree. Because if we wanted to sift through the entire tree, grep >> would be a far better method (compiled C and probably better text-matching >> algorithms than emerge). > > And this goes pretty much backwards to what we were aiming at. We > should finally kill use.desc.local, not get inspired by the redundancy. And what replaces it? What differentiates a global USE flag that has purpose across multiple packages (like 'ipv6') against a flag that only exists for a single package? I'll agree that USE flags have definitely gotten out of control, and the trend now seems to be moving sharply away from defining a global USE definition in make.conf instead to per-package USE flags in /etc/portage/package.use. Which, while offering more granular control, can be mind-numbingly annoying at times. The automated generation of use.local.desc definitely made maintenance of some things easier. We've gotta index USE flags some how, and separating them into global and local categories still makes sense to me. But, I'm probably just going senile... >>> Worse than that, your GLEP doesn't even have any basic rules for naming >>> tags -- like what language form to use and, say, which character to use >>> instead of space. This sounds like the sort of things that's going to >>> make it even harder to get some consistency, especially if some >>> developers are going to follow someone else committing earlier and some >>> will follow their own rules. >> >> Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no >> spaces. A lot of problems are avoided if we keep tags to one-word >> descriptors only. E.g., for mail clients, they would carry both 'mail' and >> 'client' as two of their five tags. For kmail, a third tag would be 'kde' >> and Evolution would have 'gnome' instead. > > I'm pretty sure you will finally hit something that goes with two > words. Protocol name or something. Perhaps, but we can fight that battle when we get there. starting off with one-word tags keeps things simple for now and that'll make it easier to determine whether this experiment actually pans out or not. >> I'd also suggest that 'all' be considered a default, global tag for all >> packages, it be a reserved tag internal to emerge and other package >> managers, and not count against the number of allowed tags (meaning that >> technically, a package is allow five tags + 'all'). >> >> As for default
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 23/03/2014 22:08, hasufell wrote: > Michał Górny: >> Dnia 2014-03-22, o godz. 15:33:27 Alec Warner >> napisał(a): > >>> https://wiki.gentoo.org/wiki/Package_Tags >>> >>> Object or forever hold your peace. > > >> I'd honestly prefer that -- if we should really keep tags in the >> tree -- to do that with a single 'metadata/tags' file or some kind >> of hierarchy there. Keep them outside the package directory -- >> bind packages to tags, rather than tags to packages. Keep all the >> commits in a single place without altering the ebuild work flow. > > > That sounds better. That way it is also easier to get some > consistency. E.g. tags can be discussed... but adding packages to tags > is up to the maintainers. > > The GLEP should maybe cover a basic set of tags. Then projects like > games, science etc could add their sets as well which may be a bit > more specific... instead of random maintainers adding random tags. Regular user/sysadmin chipping in: This topic seems a lot like a solution seeking a problem to solve, or alternatively a dev is looking for an easy way to describe stuff. Not that there's anything wrong with that, but the proposal as written is way too vague to be useful. Tags work best when they describe narrow, clearly defined attributes, and the thing they are applied to can have one, two or more of these attributes or sometimes even none. Music and movie genres are an excellent example - there are only so many of them and for the most part one can tell whether a tag really is a genre or not. Nothing resembling such limits are proposed in this GLEP, there's not even a recommendation of what the tags will describe or how everything will be tagged equally. What happens if someone zealously over-tags all of gnome and the same thing doesn't happen for kde? Does kde just not show up in tag searches anymore? So this just seems like a nice-to-have that hasn't been properly thought through. The main stated use of it is for packages that logically belong to more than one category. So instead of a general catch all, do whatever you want mechanism, let's rather solve that exact problem by for example adding a specific field to metadata eg "supplementary categories". Pick those that apply from a clearly defined list and store the data in a clearly defined place. Such a thing can be made more generic, by making it a clear mechanism to describe extra metadata and the things to be described go through a defined process first before making it into the list. this concept is not present in the GLEP as currently written. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
Dnia 2014-03-23, o godz. 17:40:20 Joshua Kinard napisał(a): > On 03/23/2014 17:05, Michał Górny wrote: > > Dnia 2014-03-23, o godz. 16:27:43 > > Joshua Kinard napisał(a): > > > >> On 03/23/2014 15:44, Michał Górny wrote: > >>> Tags, on the other hand, are more 'live'. They place the package > >>> somewhere in the 'global' tag hierarchy that can change over time. > >>> I expect that people other than maintainers will be adding tags to > >>> packages (and changing them), and that people will invent new tags > >>> and apply them to more packages. > >>> > >>> So, first of all, your solution would mean that every commit adding > >>> a new tag or changing one of the tags would modify the package > >>> metadata.xml. This means a Manifest update and a ChangeLog entry (please > >>> don't get into more rules for ChangeLogs now), and this means it will be > >>> harder to find actually useful entries there. > >>> > >>> So we make tag updates harder, and increase time and size of rsync. > >> > >> Instead of individual lines in metadata.xml for each tag, why not a > >> single line that contains a comma-delimited list of up to five tags, > >> whitespace optional? That should help reduce the "fluff" of the tree by > >> adding this feature. > >> > >> E.g., > >> > >> one,two,three,four,five > > > > Either use XML, or don't use XML. Don't make this some kind of ugly > > mixture of XML with non-XML. > > > > So: > > > > > > one > > two > > > > > > if we're really going for this. But I guess our DTD doesn't allow easy > > definition of single with no forced position. > > TBH, I don't like the use of XML at all. Never have and never will. I am a > big fan of INI-style definitions (i.e., like Samba's config). XML just > leads to a lot of unneeded fluff in what should be a really small file, > which is why I was proposing a single element instead of multiple > elements. metadata.xml is XML at the moment, so you are supposed to obey its rules, whether you like them or not. if you want to replace it with something else, feel free to try. But don't make a shitsoup mixin out of it. > >>> Secondly, since tags for every package will be held in different files, > >>> people will need dedicated tools to collect tags from all those files > >>> and add matching tags to their own packages. Long story short, we're > >>> going to have many 'duplicate' tags that will require even more commits > >>> with ChangeLog entries and Manifest updates. > >> > >> If we automate the generation of a master tag index file, like > >> use.desc.local, this can be avoided. emerge can simply go rummage through > >> the master index for matching tag entries instead of going through the > >> entire tree. Because if we wanted to sift through the entire tree, grep > >> would be a far better method (compiled C and probably better text-matching > >> algorithms than emerge). > > > > And this goes pretty much backwards to what we were aiming at. We > > should finally kill use.desc.local, not get inspired by the redundancy. > > And what replaces it? What differentiates a global USE flag that has > purpose across multiple packages (like 'ipv6') against a flag that only > exists for a single package? Applications are supposed to read metadata.xml for local flags. That's all about it. Having an extra index file doesn't really make sense there. > >>> Worse than that, your GLEP doesn't even have any basic rules for naming > >>> tags -- like what language form to use and, say, which character to use > >>> instead of space. This sounds like the sort of things that's going to > >>> make it even harder to get some consistency, especially if some > >>> developers are going to follow someone else committing earlier and some > >>> will follow their own rules. > >> > >> Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no > >> spaces. A lot of problems are avoided if we keep tags to one-word > >> descriptors only. E.g., for mail clients, they would carry both 'mail' and > >> 'client' as two of their five tags. For kmail, a third tag would be 'kde' > >> and Evolution would have 'gnome' instead. > > > > I'm pretty sure you will finally hit something that goes with two > > words. Protocol name or something. > > Perhaps, but we can fight that battle when we get there. starting off with > one-word tags keeps things simple for now and that'll make it easier to > determine whether this experiment actually pans out or not. If you introduce arbitrary limitations, people will either find a way around them (which means getting even worse mess) or omit some tags. Either way, tags become less helpful. > >> I'd also suggest that 'all' be considered a default, global tag for all > >> packages, it be a reserved tag internal to emerge and other package > >> managers, and not count against the number of allowed tags (meaning that > >> technically, a package is allow five tags + 'all'). > >> > >> As for default tags when a package does
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 03/23/2014 17:51, Michał Górny wrote: > Dnia 2014-03-23, o godz. 17:40:20 > Joshua Kinard napisał(a): > >> On 03/23/2014 17:05, Michał Górny wrote: >>> Dnia 2014-03-23, o godz. 16:27:43 >>> Joshua Kinard napisał(a): >>> On 03/23/2014 15:44, Michał Górny wrote: > Tags, on the other hand, are more 'live'. They place the package > somewhere in the 'global' tag hierarchy that can change over time. > I expect that people other than maintainers will be adding tags to > packages (and changing them), and that people will invent new tags > and apply them to more packages. > > So, first of all, your solution would mean that every commit adding > a new tag or changing one of the tags would modify the package > metadata.xml. This means a Manifest update and a ChangeLog entry (please > don't get into more rules for ChangeLogs now), and this means it will be > harder to find actually useful entries there. > > So we make tag updates harder, and increase time and size of rsync. Instead of individual lines in metadata.xml for each tag, why not a single line that contains a comma-delimited list of up to five tags, whitespace optional? That should help reduce the "fluff" of the tree by adding this feature. E.g., one,two,three,four,five >>> >>> Either use XML, or don't use XML. Don't make this some kind of ugly >>> mixture of XML with non-XML. >>> >>> So: >>> >>> >>> one >>> two >>> >>> >>> if we're really going for this. But I guess our DTD doesn't allow easy >>> definition of single with no forced position. >> >> TBH, I don't like the use of XML at all. Never have and never will. I am a >> big fan of INI-style definitions (i.e., like Samba's config). XML just >> leads to a lot of unneeded fluff in what should be a really small file, >> which is why I was proposing a single element instead of multiple >> elements. > > metadata.xml is XML at the moment, so you are supposed to obey its > rules, whether you like them or not. if you want to replace it with > something else, feel free to try. But don't make a shitsoup mixin out > of it. I'm not proposing to change it now...bit too late for that. But if I ever come across a TARDIS on eBay, well... That said, Is XML that specific that every single atom has to be wrapped by an individual tag? A comma-separated list of values in its own XML tag is prohibited by the spec? I don't use XML often (if at all), so I am not familiar with its intrinsics. > Secondly, since tags for every package will be held in different files, > people will need dedicated tools to collect tags from all those files > and add matching tags to their own packages. Long story short, we're > going to have many 'duplicate' tags that will require even more commits > with ChangeLog entries and Manifest updates. If we automate the generation of a master tag index file, like use.desc.local, this can be avoided. emerge can simply go rummage through the master index for matching tag entries instead of going through the entire tree. Because if we wanted to sift through the entire tree, grep would be a far better method (compiled C and probably better text-matching algorithms than emerge). >>> >>> And this goes pretty much backwards to what we were aiming at. We >>> should finally kill use.desc.local, not get inspired by the redundancy. >> >> And what replaces it? What differentiates a global USE flag that has >> purpose across multiple packages (like 'ipv6') against a flag that only >> exists for a single package? > > Applications are supposed to read metadata.xml for local flags. That's > all about it. Having an extra index file doesn't really make sense > there. But they don't currently, do they? As far as I know, most everything parses the use.local.desc file. Wouldn't having portage apps read/parse every package's metadata.xml file introduce a lot of disk I/O to seek out those files across the entire tree? That would seem like a bigger step backwards if so. > Worse than that, your GLEP doesn't even have any basic rules for naming > tags -- like what language form to use and, say, which character to use > instead of space. This sounds like the sort of things that's going to > make it even harder to get some consistency, especially if some > developers are going to follow someone else committing earlier and some > will follow their own rules. Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no spaces. A lot of problems are avoided if we keep tags to one-word descriptors only. E.g., for mail clients, they would carry both 'mail' and 'client' as two of their five tags. For kmail, a third tag would be 'kde' and Evolution would have 'gnome' instead. >>> >>> I'm pretty sure you will finally hit something that goes with two >>> words. Protocol name o
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 24 March 2014 11:54, Joshua Kinard wrote: > That said, Is XML that specific that every single atom has to be wrapped by > an individual tag? A comma-separated list of values in its own XML tag is > prohibited by the spec? I don't use XML often (if at all), so I am not > familiar with its intrinsics. > By nesting CSV inside XML, you've now got 2 formats to deal with instead of 1. In pure XML, you can get a properly decoded array of tag elements with a simple XPath query: //tag But with CSV-in-a-tag you have to extract the tag and subsequently parse it. So you're hand implementing a parser to parse parts of XML that already convey data without needing to hand-parse. Which is more effort for everyone who touches the file, not less. Add to that automated ways to update the tags ( again, having to implement a custom serialiser in addition to the custom parser ) and its just not worth the tiny amount of savings. Because really, if space efficiency was #1 priority, we'd not be using XML at all, let alone XML with pesky whitespace indentation that consumes needless bytes. =) -- Kent
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 03/23/2014 19:18, Kent Fredric wrote: > On 24 March 2014 11:54, Joshua Kinard wrote: > >> That said, Is XML that specific that every single atom has to be wrapped by >> an individual tag? A comma-separated list of values in its own XML tag is >> prohibited by the spec? I don't use XML often (if at all), so I am not >> familiar with its intrinsics. >> > > > By nesting CSV inside XML, you've now got 2 formats to deal with instead of > 1. > > In pure XML, you can get a properly decoded array of tag elements with a > simple XPath query: > > //tag > > But with CSV-in-a-tag you have to extract the tag and subsequently parse it. I am probably thinking from a Python perspective then. All you have to do is grab the value of and then split it on the comma. No custom parsing needed, since that function is built into Python. I guess this might not be the case with other languages, though, and it really just adds to my distaste of XML as a format for metadata.xml in the first place. > So you're hand implementing a parser to parse parts of XML that already > convey data without needing to hand-parse. > > Which is more effort for everyone who touches the file, not less. > > Add to that automated ways to update the tags ( again, having to implement > a custom serialiser in addition to the custom parser ) and its just not > worth the tiny amount of savings. > > Because really, if space efficiency was #1 priority, we'd not be using XML > at all, let alone XML with pesky whitespace indentation that consumes > needless bytes. =) I guess I need to start looking for used TARDISes then... Thanks for the explanation. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-03-23 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-03-23 23h59 UTC. Removals: virtual/emacs-cedet 2014-03-17 00:30:00 ulm gnustep-libs/cddb 2014-03-17 10:15:57 voyageur app-emacs/nxml-mode 2014-03-17 20:48:30 ulm app-emacs/erc 2014-03-17 20:50:42 ulm app-emacs/cperl-mode2014-03-17 20:53:10 ulm app-emacs/alt-font-menu 2014-03-17 20:55:21 ulm app-emacs/u-vm-color2014-03-17 20:59:07 ulm app-emacs/eperiodic 2014-03-20 08:21:02 ulm app-emacs/view-process 2014-03-20 08:22:44 ulm media-sound/audio-entropyd 2014-03-22 15:05:09 angelos app-emacs/http-emacs2014-03-23 15:41:11 ulm app-emacs/mairix2014-03-23 15:41:47 ulm Additions: dev-python/dugong 2014-03-17 09:03:32 radhermit mate-base/mate-applets 2014-03-17 21:13:24 tomwij mate-extra/caja-dropbox 2014-03-17 21:28:08 tomwij mate-extra/mate-file-manager-image-converter2014-03-17 21:56:30 tomwij mate-extra/mate-file-manager-open-terminal 2014-03-17 22:17:55 tomwij mate-extra/mate-file-manager-sendto 2014-03-17 22:39:11 tomwij mate-extra/mate-file-manager-share 2014-03-17 23:11:45 tomwij dev-util/emilpro2014-03-18 04:26:05 zerochaos kde-misc/kcmsystemd 2014-03-18 22:17:59 johu profiles/arch/arm64 2014-03-19 00:12:41 dilfridge media-gfx/mate-image-viewer 2014-03-19 16:24:25 tomwij x11-misc/mate-menu-editor 2014-03-19 16:34:15 tomwij net-analyzer/mate-netspeed 2014-03-19 16:41:51 tomwij x11-misc/mate-notification-daemon 2014-03-19 16:50:58 tomwij x11-themes/mate-icon-theme-faenza 2014-03-19 17:21:41 tomwij dev-ruby/rb-readline2014-03-19 18:26:21 zerochaos profiles/default/linux/arm642014-03-19 22:13:22 dilfridge profiles/default/linux 2014-03-19 22:20:41 dilfridge dev-vcs/hg-fast-export 2014-03-21 22:34:00 ottxor sys-apps/audio-entropyd 2014-03-22 15:00:30 angelos dev-vcs/git-flow2014-03-22 15:49:16 johu app-emacs/gnuplot-mode 2014-03-22 16:17:15 ulm app-admin/mate-system-tools 2014-03-22 19:00:12 tomwij mate-extra/mate-media 2014-03-22 19:37:52 tomwij mate-base/mate-control-center 2014-03-22 20:52:05 tomwij net-misc/portspoof 2014-03-22 22:51:32 zerochaos app-leechcraft/lc-ooronee 2014-03-23 14:42:19 maksbotan app-leechcraft/lc-cpuload 2014-03-23 14:42:19 maksbotan app-leechcraft/lc-certmgr 2014-03-23 14:42:19 maksbotan mate-extra/mate-user-share 2014-03-23 16:26:27 tomwij -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: virtual/emacs-cedet,removed,ulm,2014-03-17 00:30:00 gnustep-libs/cddb,removed,voyageur,2014-03-17 10:15:57 app-emacs/nxml-mode,removed,ulm,2014-03-17 20:48:30 app-emacs/erc,removed,ulm,2014-03-17 20:50:42 app-emacs/cperl-mode,removed,ulm,2014-03-17 20:53:10 app-emacs/alt-font-menu,removed,ulm,2014-03-17 20:55:21 app-emacs/u-vm-color,removed,ulm,2014-03-17 20:59:07 app-emacs/eperiodic,removed,ulm,2014-03-20 08:21:02 app-emacs/view-process,removed,ulm,2014-03-20 08:22:44 media-sound/audio-entropyd,removed,angelos,2014-03-22 15:05:09 app-emacs/http-emacs,removed,ulm,2014-03-23 15:41:11 app-emacs/mairix,removed,ulm,2014-03-23 15:41:47 Added Packages: dev-python/dugong,added,radhermit,2014-03-17 09:03:32 mate-base/mate-applets,added,tomwij,2014-03-17 21:13:24 mate-extra/caja-dropbox,added,tomwij,2014-03-17 21:28:08 mate-extra/mate-file-manager-image-converter,added,tomwij,2014-03-17 21:56:30 mate-extra/mate-file-manager-open-terminal,added,tomwij,2014-03-17 22:17:55 mate-extra/mate-file-manager-sendto,added,tomwij,2014-03-17 22:39:11 mate-extra/mate-file-manager-share,added,tomwij,2014-03-17 23:11:45 dev-util/emilpro,added,zerochaos,2014-03-18 04:26:05 kde-misc/kcmsystemd,added,johu,2014-03-18 22:17:59 profiles/arch/arm64,added,dilfridge,2014-03-19 00:12:41 media-gfx/mate-image-viewer,added,tomwij,2014-03-19 16:24:25 x11-misc/mate-menu-editor,add
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sun, 23 Mar 2014 23:47:22 +0200 Alan McKinnon wrote: > Tags work best when they describe narrow, clearly defined attributes, > and the thing they are applied to can have one, two or more of these > attributes or sometimes even none. Music and movie genres are an > excellent example - there are only so many of them and for the most > part one can tell whether a tag really is a genre or not. There are more ways to search for a music or a movie than a genre: What mood is it in? What are key elements of its plot or lyrics? Where does it take place? For which audience is it meant? Which praises has it received? What kind of style is it made in? What is it based on? What is the attitude of it? What looks or effects does it have? Is it appropriate for children? Does it contain explicit things? Let's do this for movies. I'm looking for a ... ... serial killer (key element) that is scary (mood)? Carrie, Halloween, Saw, Scream, ... ... musical (genre) that makes one feel good (mood)? Aaja Nachle, Frozen, Grease, The Sound of Music, ... ... good versus evil (plot) based on comics (based on)? Batman, Sin City, Superman, The Avengers, ... ... goofy (attitude) hero (key element) where nothing goes right (plot)? Due Date, Faulty Towers, Monty Python's Flying Circus, Mr Bean, ... These are results from an actual movie recommendation site; similarly, the same exists for music too, where you can for example look for a female american singer-songwriter singing catchy contemporary country. Getting back to Gentoo; when I would look for some package, I want it to be a lightweight, do audio recordings, organize these audio recordings and do effects on these audio recordings. So, I'll be looking for tags like "lightweight, audio-recording, file-organization, sound-effects"; if that's to broad, I can take two of them and test some of that. Thinking about the different types of things to search for; I'm thinking about ... ... what the characteristics of the software are (light/heavy, new/old, extensible/modular/nonstandard, ...), ... what the software can do (record audio, organize files, ...), ... what category (browser, development, DAW software, utility, ...), ... what kind of interface the software has to me (CLI, GUI, ...), ... what interconnectivity the software has (internet, bluetooth, ...), ... and so on ... We could make a list of types (some already mentioned above) and a list of possible tags for that type to shape the tag system somewhat. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sun, 23 Mar 2014 16:03:38 +0100 Alexander Berntsen wrote: > On 23/03/14 15:46, Jeroen Roovers wrote: > > "This GLEP author would love to blight categories out of gentoo > > history as a giant mistake." That's not what I wrote. It's a quotation. > It does not matter. Just remove that line. It is irrelevant. The point in asking why it's there was to establish why the GLEP as a whole is relevant. In other words: it would be trivial[1] yet pains-taking[2] to establish an alternative means to address the package manager to package targets, but why would we want to do it? Examples of where atoms fail and where tags do better could enlighten us. jer [1] Set up a PM wrapper that translates tags into atoms. [2] Set up a database of such translations, with a really easy fail-over to ordinary atoms where the database is incomplete.
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sat, Mar 22, 2014 at 6:33 PM, Alec Warner wrote:
> https://wiki.gentoo.org/wiki/Package_Tags
>
Ack, this had to happen on a weekend when I wasn't paying attention!
And you beat me to it, too-- I was working on something in this vein,
but wasn't quite satisfied with the design yet. Oh well. You're sort
of on the right track, but there are some very important aspects
missing that will make the whole thing collapse with their absence.
(This thread has been in various places, but I frankly don't feel like
finding the relevant snippets, so you get a text dump. Sorry about
that.)
The first thing missing is aliasing (most proposals for this sort of
system miss this at first; don't feel too bad). There are many, many,
many cases where you want more than one single tag query to resolve to
the same canonical tag. The ability to define aliases that take care
of this automatically is critical. In my notes on this, I had a
global alias file, and users can have an /etc/portage/tag.alias. It's
just text -- nothing special -- that defines antecedent = consequent
relationships. This means the antecedent is _replaced_ by the
consequent. As a quick example, cpp = c++ This also allows for simple
changes to the canonical name.
Second, implication is important for decreasing maintenance burden.
An implication is an antecedent -> consequent relationship where the
consequent is automatically added if the antecedent is present.
Unlike aliasing, the consequent doesn't _replace_ the antecedent. An
example of this is acpi -> power_management, because acpi is a
distinct aspect of power management, and has value on its own. Over
time, this significantly lowers the maintenance burden of an expanding
vocabulary and tree.
With that in place, I want to make something clear: consistency in the
vocabulary is absolutely critical. I cannot overemphasise how
important this is. Adding tags without any sort of discipline leads
to an unmaintainable vocabulary, which makes the whole thing as
worthless as some people think. So there needs some sort of basic
canonical list of tags with their descriptions, and yes people should
be expected to be rigourous in how they approach this. I've attached
a rough draft of descriptions and aliases that I pulled together a
while ago (analogous to /etc/portage/profiles/use.desc).
This is where aliasing becomes essential, because it allows us to
guarantee some amount of consistency. We're only human and can't be
expected to cover every situation, but there's plenty of low-hanging
fruit in this area. e.g.:
app = application # Alias abbreviation to full tag
editors = editor# Make plural -> singular
aliases standard where sensible.
# Rule of thumb 1: "This is a(n)..."
admin = administration # Rule of thumb 2: "This is
a(n)... ...tool"
backup = back-up# Can use hyphenated forms
benchmark = benchmarking# As with admin, only gerund form.
cdr = disk_authoring# Spaces replaced with
underscores at word boundaries
i18n = internationalisation # Will need to come to a
consensus on the s/z spelling and make some aliases.
cpp = c++ # Valid tags should be
restricted to basic ASCII minus spaces (replaced with underscores) for
our own sanity
.net = dotnet # This could go either way,
but the leading period makes my Unix blood distrust it.
gamedev = game_development # "games" becomes ambiguous
with "game" so prefer a more-clear form.
lang = language = programming_language # Not to be confused with the
i18n language support. Avoid confusion with clear naming
version_control = source_control = vcs # Well known abbreviations can
be used in place of their expansions
mail = email# No sense not being clear
mail_server = mail_transfer_agent = mta # Multiple aliases to the same
thing are acceptable
nntp = {{newsreader usenet}}# The braced notation denotes
an intersection of two tags. Need to decide if this sort of alias is
legal. I'm thinking no, honestly.
sys = system# BUT it's in conflict with
@system! Don't do that.
www = web # These are all things that
deal with the web specifically.
apache = apache_module # classes of packages that
have their own categories is exactly why this is a good idea.
The above is just an excerpt copied directly from my notes on
aliasing. Some other stuff:
- Query syntax and semantics can be addressed in greater detail later.
There's some nice sugar to be had here.
- Likewise, tools. Something along the lines of quse and equery would
be handy in support of this.
- Aliases for reasonable search terms are not a bad idea.
- I've stated at various points in the past, but categories are
already tags after a fashion. They're not ve
