[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
From:       "Rick \"Zero_Chaos\" Farina" <zerochaos () gentoo ! org>
Date:       2013-08-31 5:37:22
Message-ID: 52218112.2000606 () gentoo ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> The new eclass is supposedly used by 732 in-tree packages [1],
> and possibly a few dozens out-of-the-tree. Some parts of the eclass API
> are barely used. I would really prefer to avoid yet another eclass
> migration.

that's a shame, I don't think it is avoidable with the changes you are
suggesting

> However, I would like to do a few breaking changes to simplify
> the eclass and its maintenance:
> 
> 1. Make EGIT_SOURCEDIR default to ${WORKDIR}/${P} rather than ${S}
>    (to support setting S to subdirectory of git repo),
> 
> 2. Kill EGIT_HAS_SUBMODULES and autodetect submodules,
> 
> 3. Kill EGIT_OPTIONS since it limits the possibility of changing eclass
>    code,
> 
> 4. Kill EGIT_MASTER (it's more trouble than benefit),
> 
> 5. Possibly kill EGIT_PROJECT -- it won't be good enough anymore,
> 
> 6. Kill EGIT_NONBARE and support bare checkouts only. Supporting two
>    different layouts introduces a lot redundant code.
> 
> 7. Kill EGIT_NOUNPACK -- possibly replace it with proper fetching
>    function, or just src_fetch(),
> 
> 8. Kill EGIT_DIR -- it supposedly should not even be overriden.
> 
These changes will cause significant breakage.  That is fine for
migration, but not for in place eclass changes.
> 
> But it's not all removing. There are also a few things I would like to
> change/add:
> 
> 1. Replace 'git clone' with 'git init' + 'git fetch' that would be
>    a bit simpler,
> 
> 2. Add complete & working support for shallow clones, and make it the
>    default. This means a lot of space-saving for people who only use
>    the repos for ebuilds.
> 
> 3. Add complete & proper support for submodules. Currently, submodules
>    enforce non-bare clones and are fetched during unpack. After
>    the change, they will be fetched and unpacked like normal repos.
> 
> 
> The use of API features in *.ebuild maps like the following;
> 
> EGIT_REPO_URI	521
> EGIT_BRANCH	66
> EGIT_SOURCEDIR	21
> EGIT_PROJECT	17
> EGIT_HAS_SUBMODULES	15
> EGIT_COMMIT	12
> EGIT_BOOTSTRAP	12
> EGIT_MASTER	7
> EGIT_NOUNPACK	2
> EGIT_STORE_DIR	1
> EGIT_NONBARE	1
> EGIT_DIR	1
> EVCS_OFFLINE	0 // these are for make.conf
> EGIT_REPACK	0
> EGIT_PRUNE	0
> EGIT_OPTIONS	0
> 
> I will need to take a look which of those cases can be replaced easily.
> 
> 
> How should I proceed? Assuming that git-2.eclass is used by live
> ebuilds only, and those ebuilds can be subject to random breakage,
> I could supposedly just start changing API of the eclass.
> 
negative, breaking ebuilds is different than upstream breaking things
and needing ebuild fixes.  Randomly breaking 700+ ebuilds isn't cool.

> On the other hand, I could also go for beautiful git-r1.eclass,
> and cleanly switch the packages.
> 
> Then, I could go for something involving the two -- create a new
> git-r1.eclass that has API fully stripped, and start deprecating
> features from git-2.eclass. We would be able to switch to git-r1 to
> test offending packages safely, then do a big switch of remaining
> packages and make the two eclasses temporarily equivalent.
> 
> What are your thoughts?
> 
I have a VCS ebuild for nearly everything I officially maintain and
almost everything in the pentoo overlay.  If you change the eclass in
place that will break dozens of ebuilds just for me.  Please don't.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSIYESAAoJEKXdFCfdEflKdXUQAI3Rwqyku4FCgO/3uivB/ltN
+pDlw0DCHt9IlBK1Jh3t+ohXVdXhi6iZyQ7ly+t+5phA3zhR79yTJWkxmXq8E7br
TM99Fsfd3Cqmdc54F4uA6MHI9MQj7efCkE3mas9bks8SPBnNTVwWmjVYUxBXZXfm
J94+tcCEdesVqz2/iivm0iQ6W7EraCTG+umz/wz1urqIfDQBO8mDLHoM+jiovnUb
tArOZ3GIhS/Rj+S/ZtH4VpvarFrH5ZzfO1GpNAvaFS8kGLRdEoUnMYk6K+WNdbkZ
SYldaL8M/gNKWfmRU+j8OGK7bsNJx43Bqei7oUyMqkUVsTBpjmkPvw59aFKVlb7J
kdfeoobpFsuAcxaQfWU1J8map82N8McdVOYMkEkC3HJP33TeymZKSUcU2/iMxr1W
+kU0C2L7A9oXzWwkmiQ9WxAQ5KTYzyh5AzaaN45pju+QlFc2T4P4AZ4oqy+Zzzi2
CH2JZBPdv9+jMQLcwhpVoDsOPbbLGrx/aJEARwKvgs2fF+WYllraOu7uMPnaoYWw
wNK9JYyhncx2pfG23PG7Uo3RtN8Aks0tptsHosOmB9ZArtnhYL2SxlotAoef+9X7
2qxFm59D9koW5FF0arnzzF/ul2zzos7NZRwJ1bwR1gYocxvN6Yqfg0zeX6uC+sDW
dSukBOrVEuyftf+KurL9
=harh
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]