Re: [gentoo-dev] Re: .gitignore

[wireless]

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