Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?
On Wed, 18 Jul 2018 13:47:03 +0100 "M. J. Everitt" wrote: > - Line one is limited to / and some Key Word that defines > the type of change made, similar to bugzilla perhaps eg. "REVBUMP, > VERBUMP, EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get > around the issue of long package-names and/or overlays and other > lengthy prefixes. Hell no. I want to see as *much* data as possible in the limited summary, not the *LEAST*. That's why we have this problem in the first place: Developers are trying *HARD* to put sufficiently quality information. This proposal as-is basically champions the line length limitation to absurdity. If you go down this road you may as well "Fix" the problem by forcing everyone to make the commit summary the shortened SHA1 of the rest of the text in the commit message at least that way you're *GUARANTEED* to never exceed 50 odd characters. The commit summary will be useless, but hey, we got that message length down alright. Yay! pgpd2migo1z58.pgp Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: net-news/rssguard,...
Dear all, The following packages are up for grabs: net-news/rssguard games-emulation/ppsspp games-strategy/colobot games-strategy/colobot-data app-crypt/zulucrypt net-misc/trackma net-misc/streamlink app-admin/profile-cleaner after retirement of the proxied maintainer. https://packages.gentoo.org/packages/net-news/rssguard https://packages.gentoo.org/packages/games-emulation/ppsspp https://packages.gentoo.org/packages/games-strategy/colobot https://packages.gentoo.org/packages/games-strategy/colobot-data https://packages.gentoo.org/packages/app-crypt/zulucrypt https://packages.gentoo.org/packages/net-misc/trackma https://packages.gentoo.org/packages/net-misc/streamlink https://packages.gentoo.org/packages/app-admin/profile-cleaner Most of these packages have open bugs. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Objections to renaming pym directory to lib?
On Wed, Jul 18, 2018 at 4:36 PM, Michał Górny wrote: > W dniu śro, 18.07.2018 o godzinie 13∶51 -0400, użytkownik Alec Warner > napisał: > > On Wed, Jul 18, 2018 at 2:54 AM, Brian Dolbec wrote: > > > > > On Tue, 17 Jul 2018 13:28:05 -0700 > > > Zac Medico wrote: > > > > > > > Are there any objections to renaming the pym directory to lib [1]? > > > > Note that the git log --follow option makes this kind of rename > > > > fairly painless. > > > > > > > > [1] https://github.com/gentoo/portage/pull/343 > > > > > > is fine with me > > > > > > > Are we leaving symlinks; or we think (non-portage) tools won't need to > care > > about this name change? > > > > It affects only the source tree; it doesn't affect installed Portage. > Ah, then go for it ;) > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] Re: What means bup?
Am 18.07.2018 um 09:26 schrieb Matthew Thode: > On 18-07-18 09:16:07, Johannes Huber wrote: >> Hi all, >> >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. >> > > It's similiar to a sound you make when you touch something's nose. > *boop* > > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). > Hi Matthew, thank you for the explanation. As the ChangeLogs are expanded for rsync or can be inspected via git I would expect from a user standpoint to read proper entries. Thanks in advance, Johannes signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Objections to renaming pym directory to lib?
W dniu śro, 18.07.2018 o godzinie 13∶51 -0400, użytkownik Alec Warner napisał: > On Wed, Jul 18, 2018 at 2:54 AM, Brian Dolbec wrote: > > > On Tue, 17 Jul 2018 13:28:05 -0700 > > Zac Medico wrote: > > > > > Are there any objections to renaming the pym directory to lib [1]? > > > Note that the git log --follow option makes this kind of rename > > > fairly painless. > > > > > > [1] https://github.com/gentoo/portage/pull/343 > > > > is fine with me > > > > Are we leaving symlinks; or we think (non-portage) tools won't need to care > about this name change? > It affects only the source tree; it doesn't affect installed Portage. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Objections to renaming pym directory to lib?
On Wed, Jul 18, 2018 at 2:54 AM, Brian Dolbec wrote: > On Tue, 17 Jul 2018 13:28:05 -0700 > Zac Medico wrote: > > > Are there any objections to renaming the pym directory to lib [1]? > > Note that the git log --follow option makes this kind of rename > > fairly painless. > > > > [1] https://github.com/gentoo/portage/pull/343 > > is fine with me > Are we leaving symlinks; or we think (non-portage) tools won't need to care about this name change? -A
Re: [gentoo-dev] Re: What means bup?
On 18-07-18 11:28:16, Mike Gilbert wrote: > On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode > wrote: > > On 18-07-18 09:16:07, Johannes Huber wrote: > >> Hi all, > >> > >> english is not my mother language, so please clarify what bup means, just > >> seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > >> > > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > > > I just prefer bup instead. I generally only use it when doing simple > > bumps of packages (copy ebuilds with only keyword edits). > > My preference is to mention the version being added when committing a > version bump. eg. "cat/pkg: bump to x.y.z". > > Yes, it does take a few more seconds, but I think it is worth the effort. > I think more recently I've been following this format. cat/pkg: x.y.z bup -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On July 18, 2018 2:55:55 AM PDT, Ulrich Mueller wrote: >It was mentioned that all three directories (ebuild repository, binary >packages, distfiles) have some characteristics of a cache. However, I >think this is much more true for distfiles than for the other two, >which cannot be easily restored to a previous state. Neither can a Web browser’s cache, if the remote page has changed, yet those are still called caches. Surely a cache is something that can safely be discarded without negative impact (which, for most users, the ebuild tree can be, since for most users, getting back today’s tree rather than last week’s is not a negative impact), not something that can be restored to exactly its prior state automatically. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode wrote: > On 18-07-18 09:16:07, Johannes Huber wrote: >> Hi all, >> >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. >> > > It's similiar to a sound you make when you touch something's nose. > *boop* > > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). My preference is to mention the version being added when committing a version bump. eg. "cat/pkg: bump to x.y.z". Yes, it does take a few more seconds, but I think it is worth the effort.
Re: [gentoo-dev] Re: What means bup?
On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode wrote: > On 18-07-18 09:16:07, Johannes Huber wrote: >> Hi all, >> >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. >> > > It's similiar to a sound you make when you touch something's nose. > *boop* > > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). Cute. Since 94.5% of the 1248 instances were from you... can you please stop?
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Wed, Jul 18, 2018 at 9:30 AM Ulrich Mueller wrote: > > > On Wed, 18 Jul 2018, Rich Freeman wrote: > > > On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller wrote: > >> Also, there is that strange requirement that the > >> file hierarchy must not be exposed to users. At least for the > >> make.profile link we rely on a well defined hierarchy, and certainly > >> expose it to users. > > > That isn't true at all. When you run eselect profile you have no idea > > what it is looking at. > > If I run eselect profile, it shows a list of pathnames like > default/linux/amd64/17.1/desktop. If that doesn't expose the "specific > file hierarchy" then I wonder what could ever qualify? It lists profile names. The fact that our profiles are implemented using paths is an implementation detail. And you would have no idea that they're stored in /usr or /var from the output of eselect. If we modified PMS so that profiles were stored in a mysql database the current eselect output could work just fine. > Also eselect profile is a tool for convenience only, and nobody is > forced to use it. The make.profile symlink and its target are > mentioned in our documentation and users can set it manually. So is /var/lib/portage/world. Are you planning to move that to /etc? (I wouldn't object to that, actually.) Personally I think that a lot of this comes from the standpoint of a typical distro where command lines are things that should be hidden as deeply in the gnome menus as possible. But, my point is that if you want that kind of experience on Gentoo it is certainly possible insofar as profiles are concerned. > Hopefully we will keep having such users who want to understand the > inner workings, instead of being satisfied with a black box. :) > Ebuild repositories are human readable text, and we shouldn't move > them to a hidden location. There is nothing hidden about /var/lib. And I also prefer editing text files for the most part. My point is that FHS wasn't really written with Gentoo as its main target, and that is likely the reason for the bit about hiding paths. > > >> The same is true for license information in > >> /usr/portage/licenses. > > > You have a fair point there. Honestly, I don't really see this as a > > good reason on its own to abandon /var/lib, which is where other > > distros seem to stick stuff like this. Also, you don't need to poke > > around that directory to determine what license a package uses - just > > to read the text of the license itself (which could arguably just be > > stored on our webserver unless we're actually redistributing something > > in the repository under that license, which is unlikely in general > > since patches/etc are probably fair use). > > I totally disagree here. We keep local copies of licenses for good > reasons, and storing them on our webserver is no substitute. I'm not sure what you're disagreeing with. I'm not advocating for not storing them locally. I'm just saying it could be done, and I did say that you had a fair point. > No, the argument is that we already use /var/db/pkg, and grouping > other related things with it seems natural. Perhaps we should be trying to move away from using /var/db, and not doubling down? > Apart from this (quoting the devmanual): "Gentoo does not consider > the Filesystem Hierarchy Standard to be an authoritative standard, > although much of our policy coincides with it." And the discussion so > far has shown that the FHS wasn't designed for our use case. We can > still use it as a guideline, but maybe we shouldn't jump through > hoops, only to make it completely fit. Sure, I'd agree with that, but why not use /var/lib then? Your only argument against it is based on the FHS, which you freely concede wasn't written to fit our use case. > The only thing that seems certain is that regardless of what we will > do, we cannot make everybody happy. We shouldn't take that as an > excuse to do nothing, because /usr/portage is no good solution either. Well, the one thing I like about all these proposals is that it will result in Gentoo systems with a wide mixture of locations for these things, which will guarantee that any script that hard-codes paths will break. That means that those who exercise their choice to do things in a more sane way than our defaults will probably run into less trouble... -- Rich
Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?
M. J. Everitt wrote: > I'm thinking something along the lines of the following: > - Line one is limited to / and some Key Word that defines the > type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP, > EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the > issue of long package-names and/or overlays and other lengthy prefixes. This would remove one of two information atoms in commit messages, reducing human expression in commit messages to mere 50%, or to 0% for --oneline output. I think that's unacceptably poor usability. > This should satisfy line length limitations, My counter-proposal is to bup the repoman line length limitation. //Peter
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
> On Wed, 18 Jul 2018, Rich Freeman wrote: > On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller wrote: >> Also, there is that strange requirement that the >> file hierarchy must not be exposed to users. At least for the >> make.profile link we rely on a well defined hierarchy, and certainly >> expose it to users. > That isn't true at all. When you run eselect profile you have no idea > what it is looking at. If I run eselect profile, it shows a list of pathnames like default/linux/amd64/17.1/desktop. If that doesn't expose the "specific file hierarchy" then I wonder what could ever qualify? Also eselect profile is a tool for convenience only, and nobody is forced to use it. The make.profile symlink and its target are mentioned in our documentation and users can set it manually. > The fact that some of our users like to poke around the internals of > the package manager doesn't change the fact that it has interfaces > that don't require direct modification. Hopefully we will keep having such users who want to understand the inner workings, instead of being satisfied with a black box. :) Ebuild repositories are human readable text, and we shouldn't move them to a hidden location. >> The same is true for license information in >> /usr/portage/licenses. > You have a fair point there. Honestly, I don't really see this as a > good reason on its own to abandon /var/lib, which is where other > distros seem to stick stuff like this. Also, you don't need to poke > around that directory to determine what license a package uses - just > to read the text of the license itself (which could arguably just be > stored on our webserver unless we're actually redistributing something > in the repository under that license, which is unlikely in general > since patches/etc are probably fair use). I totally disagree here. We keep local copies of licenses for good reasons, and storing them on our webserver is no substitute. >> This follows the existing usage in eselect-repositories. Note that >> /var/db is not specified by the FHS (though it is mentioned in a >> footnote [1]) but used by all current BSD variants. Plus, we already >> have /var/db/pkgs and (as pointed out by antarus) we won't get rid of >> it anytime soon. > So, you reject one path on the basis of small conflicts with FHS, and > then just toss FHS out the window entirely to use a path not specified > at all? No, the argument is that we already use /var/db/pkg, and grouping other related things with it seems natural. > If you want to appeal to what BSD is doing then /usr/portage belongs > right where it is today. Oh, and most of our packages should be > installing to /usr/local as well. As I said before, the two important parts are the move from /usr to /var, and that distfiles and packages are moved out of the repository. Apart from this (quoting the devmanual): "Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it." And the discussion so far has shown that the FHS wasn't designed for our use case. We can still use it as a guideline, but maybe we shouldn't jump through hoops, only to make it completely fit. > What other linux distro even has /var/db at all? Many (most?) of those that build from source. Also, Gentoo is not only a Linux distro. >> /usr/portage/packages -> /var/db/binpkgs > Why not put this in /var/cache? It is completely reproducible and > exists to save build time. That's what a cache is. *shrug* I don't have a strong opinion about this. To me, binpkgs look less cache-like than distfiles, but more cache-like than ebuild repositories. So /var/cache/binpkgs would work for me as well. The only thing that seems certain is that regardless of what we will do, we cannot make everybody happy. We shouldn't take that as an excuse to do nothing, because /usr/portage is no good solution either. Ulrich pgppLkw8SOPNi.pgp Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On Wed, 18 Jul 2018 14:20:56 +0200 Kristian Fiskerstrand wrote: > On 07/18/2018 02:10 PM, Alexis Ballier wrote: > > I often find myself in the > > need to use/invent some abbreviation in order to fit the limit. > > Considering this is an error, this sends the message that short is > > preferred over clear. > > Or that the summary should be concise and a longer proper description > can be written in the body of the commit message instead. Potentially > mixed in with multiple commits for different logical changes etc etc. > Sure, but that somewhat defeats the point of a summary if it's not possible to clearly express what it is about without relying on the long description.
[RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?
On 18/07/18 13:20, Kristian Fiskerstrand wrote: > On 07/18/2018 02:10 PM, Alexis Ballier wrote: >> I often find myself in the >> need to use/invent some abbreviation in order to fit the limit. >> Considering this is an error, this sends the message that short is >> preferred over clear. > Or that the summary should be concise and a longer proper description > can be written in the body of the commit message instead. Potentially > mixed in with multiple commits for different logical changes etc etc. > Perhaps the time has come to re-assess the commit message "standard". I'm thinking something along the lines of the following: - Line one is limited to / and some Key Word that defines the type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP, EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the issue of long package-names and/or overlays and other lengthy prefixes. - Line two remains a blank line at present - Line three+ actually describe what the change is, in plain English. - Footer~3: Bug/Pull reference - Footer~2: Signed/Authored/etc standard footer text(s) - Footer: Package manager/repoman as appropriate where: 3+ (line three onwards), ~n: approx. line prior to end (EOF-n) This should satisfy line length limitations, whilst still preserving some Basic information about commit type, which can then be sub-filtered if necessary. I can't presently see anything that would preclude tool-friendly parsing of such messages... or repoman applying appropriate checks... NB. I may have swapped F~3 and F~2 lines around .. order can be preserved as present. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On 07/18/2018 02:10 PM, Alexis Ballier wrote: > I often find myself in the > need to use/invent some abbreviation in order to fit the limit. > Considering this is an error, this sends the message that short is > preferred over clear. Or that the summary should be concise and a longer proper description can be written in the body of the commit message instead. Potentially mixed in with multiple commits for different logical changes etc etc. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On Wed, 18 Jul 2018 10:35:41 +0200 Ulrich Mueller wrote: > > On Wed, 18 Jul 2018, Matthew Thode wrote: > > > On 18-07-18 09:16:07, Johannes Huber wrote: > >> english is not my mother language, so please clarify what bup > >> means, just seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > > I just prefer bup instead. I generally only use it when doing > > simple bumps of packages (copy ebuilds with only keyword edits). > > We used to have the rule that ChangeLog messages "should be well > explained and written in clean English". I think this applies to > commit messages, too. While it does not really apply in this precise case, this rule's weight has been lowered a lot with repoman enforcing 'cat/pkg: ...' + hard limit on the commit message length. I often find myself in the need to use/invent some abbreviation in order to fit the limit. Considering this is an error, this sends the message that short is preferred over clear.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller wrote: > > "Pertains to one specific host" doesn't seem to apply to the Gentoo > repository though. Sure it does. The state of the package repository on a Gentoo host doesn't affect any other host. Sure, that state is synced from someplace that many other hosts also sync from, so the state of THAT version of the repository does affect many hosts. However, if you do an emerge --sync on one host, and then an hour later do an emerge --sync on another host, the state of either local repository won't affect the other. When they talk about things that pertain to multiple hosts they're talking about situations where a single path is often mounted across many hosts simultaneously, eg using NFS. An example of this given in FHS is /var/mail. Now, you could share the repository across multiple hosts, but that is not a typical configuration. Really, just about anything on the filesystem could potentially be shared across multiple hosts. > Also, there is that strange requirement that the > file hierarchy must not be exposed to users. At least for the > make.profile link we rely on a well defined hierarchy, and certainly > expose it to users. That isn't true at all. When you run eselect profile you have no idea what it is looking at. The fact that some of our users like to poke around the internals of the package manager doesn't change the fact that it has interfaces that don't require direct modification. > The same is true for license information in > /usr/portage/licenses. You have a fair point there. Honestly, I don't really see this as a good reason on its own to abandon /var/lib, which is where other distros seem to stick stuff like this. Also, you don't need to poke around that directory to determine what license a package uses - just to read the text of the license itself (which could arguably just be stored on our webserver unless we're actually redistributing something in the repository under that license, which is unlikely in general since patches/etc are probably fair use). > This follows the existing usage in eselect-repositories. Note that > /var/db is not specified by the FHS (though it is mentioned in a > footnote [1]) but used by all current BSD variants. Plus, we already > have /var/db/pkgs and (as pointed out by antarus) we won't get rid of > it anytime soon. So, you reject one path on the basis of small conflicts with FHS, and then just toss FHS out the window entirely to use a path not specified at all? If you want to appeal to what BSD is doing then /usr/portage belongs right where it is today. Oh, and most of our packages should be installing to /usr/local as well. What other linux distro even has /var/db at all? > /usr/portage/packages -> /var/db/binpkgs Why not put this in /var/cache? It is completely reproducible and exists to save build time. That's what a cache is. Or put it in /var/lib. Certainly your objections above don't apply to binpkgs. -- Rich
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On 07/18/2018 11:55 AM, Ulrich Mueller wrote: > I therefore suggest the following scheme: The full scheme looks good to me -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
[Moving the thread back from -project to -dev.]
> On Fri, 13 Jul 2018, Ulrich Mueller wrote:
> On Fri, 13 Jul 2018, Rich Freeman wrote:
>> Well, /var/lib/ is 3 right there. If 5 is no good then you
>> only have one left. We could just make it /var/lib/repos which seems
>> non-compliant.
> FHS 3.0 says: "An application (or a group of inter-related
> applications) must use a subdirectory of /var/lib for its data".
> Certainly /var/lib/repos is a subdirectory of /var/lib? So why would
> it be non-compliant? And if it was, do we care about non-compliance at
> the third directory level? The important part is that we move it out
> of /usr, and IMHO we should care to get the /var/{lib,cache,db} part
> somewhat right.
In the same section 5.8.1 (emphasis is mine):
"This hierarchy holds state information pertaining to an application
or the system. State information is data that programs modify while
they run, and that _pertains_to_one_specific_host._ Users must never
need to modify files in /var/lib to configure a package's operation,
and _the_specific_file_hierarchy_ used to store the data _must_not_be_
_exposed_ to regular users."
"Pertains to one specific host" doesn't seem to apply to the Gentoo
repository though. Also, there is that strange requirement that the
file hierarchy must not be exposed to users. At least for the
make.profile link we rely on a well defined hierarchy, and certainly
expose it to users. The same is true for license information in
/usr/portage/licenses. So I would conclude that using /var/lib does
not comply with the FHS.
It was mentioned that all three directories (ebuild repository, binary
packages, distfiles) have some characteristics of a cache. However, I
think this is much more true for distfiles than for the other two,
which cannot be easily restored to a previous state.
I therefore suggest the following scheme:
/usr/portage -> /var/db/repos/gentoo
This follows the existing usage in eselect-repositories. Note that
/var/db is not specified by the FHS (though it is mentioned in a
footnote [1]) but used by all current BSD variants. Plus, we already
have /var/db/pkgs and (as pointed out by antarus) we won't get rid of
it anytime soon.
/usr/portage/packages -> /var/db/binpkgs
This keeps binary packages along with ebuilds. As suggested by mgorny,
rename the "packages" directory to "binpkgs", because it is more
specific and avoids confusion with "pkgs".
/usr/portage/distfiles -> /var/cache/distfiles
Omitting the "portage" subdirectory level here, as distfiles aren't
specific to any package manager. We could use an intermediate
"package-manager" directory level, but then again, it would have only
one single subdirectory. The FHS isn't very specific about /var/cache
but mentions /var/cache/fonts as an example which appears to be
similar.
Ulrich
[1]
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#ftn.idm236086558032
pgpB26eJcfh4H.pgp
Description: PGP signature
[gentoo-dev] Re: What means bup?
> On Wed, 18 Jul 2018, Matthew Thode wrote: > On 18-07-18 09:16:07, Johannes Huber wrote: >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. > It's similiar to a sound you make when you touch something's nose. > *boop* > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). We used to have the rule that ChangeLog messages "should be well explained and written in clean English". I think this applies to commit messages, too. Ulrich pgpJC7WRzPn3h.pgp Description: PGP signature
Re: [gentoo-dev] What means bup?
180718 Johannes Huber wrote: > English is not my mother language, so please clarify what 'bup' means, > just seen here : > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 Surely, it's a typo for 'bump'. As a native speaker, I've never seen it & Dictionary.com doesn't know it. The OED is the ultimate authority on such matters, but I don't have free access : perhaps someone else does. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-dev] Re: What means bup?
On 18-07-18 09:16:07, Johannes Huber wrote: > Hi all, > > english is not my mother language, so please clarify what bup means, just > seen here: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > > Just checked if it was a typo, but can't be: > git log --oneline --grep bup | count -l > Expected 0 lines, got 1248. > It's similiar to a sound you make when you touch something's nose. *boop* I just prefer bup instead. I generally only use it when doing simple bumps of packages (copy ebuilds with only keyword edits). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] What means bup?
Hi all, english is not my mother language, so please clarify what bup means, just seen here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 Just checked if it was a typo, but can't be: git log --oneline --grep bup | count -l Expected 0 lines, got 1248. Best regards, Johannes
Re: [gentoo-portage-dev] Objections to renaming pym directory to lib?
On Tue, 17 Jul 2018 13:28:05 -0700 Zac Medico wrote: > Are there any objections to renaming the pym directory to lib [1]? > Note that the git log --follow option makes this kind of rename > fairly painless. > > [1] https://github.com/gentoo/portage/pull/343 is fine with me pgpewJwnz8KUC.pgp Description: OpenPGP digital signature
