On 08/14/2015 04:21 AM, Daniel Campbell (zlg) wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/13/2015 06:29 PM, wireless wrote:
On 08/13/2015 05:28 PM, Duncan wrote:
wireless posted on Thu, 13 Aug 2015 08:33:13 -0500 as excerpted:
On 08/12/2015 09:52 PM, Mike Frysinger wrote:
On 12 Aug 2015 18:27, Brian Dolbec wrote:
2) There is another alternate location that you can define
files to ignore locally without having to commit them to
.gitignore. Consider .gitignore a global setting. There is
another setting inside .git/info/exclude which is a local
config file that will persist and not be affected by
pulls.
as i stated, there's no reason for these paths to ever be
committed. conversely, some people (not unreasonably so) will
place files in there that have historically had known
meanings. adding these to the global gitignore is simply the
right thing to do and negatively impacts no one.
As a gentoo user now coding again, I find the need to have
things "logically organized" really helps in my efforts. Like
most others, I get codes from a variety of places and try to
follow the 'logical gentoo organization'. I use
/usr/local/portage extensively for ebuilds that I develop.
There is also /opt/ which seems to collect up a variety of
ebuilds
Confused...
What do /opt and /usr/local/portage have to do with the gentoo
repo's .gitignore, which should only need ignore settings for
locations inside the main tree, /usr/portage by default? A
.gitignore listing for /usr/portage/local and
/usr/portage/distfiles, etc, makes sense, since that's inside the
default tree location. But /opt and /usr/local/portage aren't
inside that default location and are thus about as apropos to
that as the price of tea on Mars, aren't they?
<snip> /distfiles/ /local/ /packages/ <end/snip>
Other postings in this thread mention /var/ and /usr/.... My bad, I
thought those official directories that were up for discussion on
gitignore relevancy?
/usr/portage/local was the original location for the user's own
personal ebuild space - an "overlay" if you will.
/usr/portage/distfiles and /usr/portage/packages are there
because that's where ports has put them for decades, and no-one
has gotten around to changing it in portage yet. FreeBSD defines
the use of /usr very differently to what Linux users are used
to.
Those dirs really should be in /var/portage, and the user's
overlay has no business being under main tree itself
Ok, so why is net-analyzer/jffnms found in /usr/portage/distfiles
yet it is installed in /opt/ ? If jffnms was (properly) installed
like other net-analyzer packages, would it not be in the portage
tree? There is no reason for it to remain in /opt/, that I'm aware
of. But jffnms could benefit form gitignore as other packages do,
regardless of where it is installed.
If I may take a stab at this: /usr/portage/distfiles is simply the
files Portage needs to fetch in order to extract them, build, and
install the package. If ./distfiles/ is in .gitignore, then nobody can
accidentally commit a package's source tarball or other related file.
Agreed.
/opt/ is just the installation location for the live system that it's
being installed on. The Portage tree (known forward as the Gentoo
repository) is the collection of ebuilds that allow a Gentoo system to
build the software. It's historically been in /usr/portage/, and
installs to a variety of locations, be it /bin, /sbin, /usr/bin,
/usr/sbin, /lib, and so on.
As documented here ?:
https://devmanual.gentoo.org/general-concepts/filesystem/
Without reading the ebuild, jffnms likely has special properties or is
built with specific technologies that indicate its files belong in
/opt. Given that the Gentoo repository by default resides in
/usr/portage, a .gitignore file can only apply to paths *under* that
particular path. So it would cover ./local and ./distfiles, but not
/opt, as /opt is outside the /usr/portage location and not under Git
control.
Looking at jffnms would have shed some light on the arbitrariness of
/opt/ policies. Perhaps looking more closely at /opt/ and the various
packages, you will find deviation from this aforementioned explanation.
Look, I know this whole "git" migration is a work in progress. And
everybody knows there is quite a bit of work to do on the docs and that
will take some time after the discussions have settled. What I am
suggesting is that /opt/ is a mess with sources, binaries, code-license
restriction murkyness and codes just placed there without valid
(currently) reasons. Some attention would seem integral to the
'gitignore' policies of both the gentoo-repo (tree) and the way ebuild
construction documents suggest folks use gitignore on other git repos.
That's it. No confusion at all, just a coder wanting some sanity and
robustness injected into the processes (outside of official gentoo repo)
that result in ebuilds (of sufficient quality and merit) ending up in
the gentoo-repo (portage tree). A well defined pathway, if you like.
Was I able to explain that sufficiently?
gitignore as implemented into the "gentoo repo' will have unique
policies and attribute as the devs must coalesce into a consensus. I get
that. But gitignore can also be used (and should be used) by the other
repos where code development, porting and community tweaks occur.
It would be a great idea to have some guidance (documented suggestions)
on gitignore for those efforts, particularly where codes (which will
become ebuilds) that is end up in the gentoo-repo (portage tree).
Perhaps some planning to smooth over the usage of gitignore as an
individual's suggested git-repo semantics, thus creating a clear
migration pathway for ebuilds to the gentoo repo as smooth of a
transition as possilbe. This will also clean things up a bit as GLEP 64
comes closer to being a (wonderful) reality. I really get cleaning out
the cruft (non essential or transient) files and such. Most folks do not
understand that a robust implementation of GLEP-64 complete with
auditing tools, DAGs and such, can lead to a fully audited linux system.
That is *HUGE* in the computational, controls and other forms
of fully characterized system worlds. That may not be the immediate goal
of the general gentoo dev community. But as one with several diverse
areas of engineering expertise, it is the most exciting aspect of gentoo
to date. ymmv. gitignore is a very, very important tool along that
pathway, imho.
Hopefully, I articulated this clearly and it will lead to more folks
wanting to develop ebuilds, regardless of their formal affiliations with
gentoo. I hope that more ebuild into the gentoo-repo is seen as a
positive thing.
Looking at the documentation for gitignore it would seem that the
benefits of using gitignore on those /opt/ packages could be
useful; so would it not be up to the particular package maintainer
to make that decision? Regardless of where non-devs develop
packages for gentoo, using gitignore might be useful during the
development of the packages, particularly if it is destine for the
portage tree (eventually).
Apologies in advance if I have missed some key points already
established by the gentoo dev community.... I'm certainly no whiz
with git*.
/opt is simply the chosen place for certain programs to be installed
based on how they are structured, their licensing, or the way similar
packages get handled.
Let me know when there is an updated (as I look at these discussions as
leading to 'drafts') version of this '/opt/' information in devmanual or
elsewhere, as this is currently "clear as mud" as an official policy::
"/opt: Binary-only applications."
Users can use the INSTALL_MASK variable in /etc/make.conf to exclude
any paths from having files installed, but if things break they get to
keep the pieces.
tldr .gitignore just applies to the Gentoo repository, not an entire
Gentoo system.
gitignore, should be discussed, not only as a gentoo-repo need but for
consistency on how ebuilds from overlays, and other development sites
(can) use it to make ebuild migration to the gentoo-repo relatively
straight-forward; all other factors being equal; imho.
I personally think some of this sort of coherent organization presents
gentoo in a more favorable light as a platform for all sorts of code
development.
Daniel Campbell - Gentoo Developer
James
