Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
On Sun, Sep 01, 2013 at 08:58:07PM -0400, James Cloos wrote: > > "TW" == Tom Wijsman writes: > > TW> Also, please just call it git-3.eclass as it is a major change; any > TW> other form of naming will introduce confusion (eg. -r1 < -2), also we > TW> probably shouldn't change git-2.eclass as even when masked it doesn't > TW> seem like a good thing to break its current API and documentation as > TW> well as what actually works in the Portage tree. > > +1 on all of that. git-3 is a better name than using -r1. > > And leave git-2 there for at /least/ a year. There are a LOT of out of > tree git-2 users. The last time I checked, out of tree eclass users are not a concern for how long we keep old eclasses in the tree. We only keep them until we are sure there are no in tree users. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
> "TW" == Tom Wijsman writes: TW> Also, please just call it git-3.eclass as it is a major change; any TW> other form of naming will introduce confusion (eg. -r1 < -2), also we TW> probably shouldn't change git-2.eclass as even when masked it doesn't TW> seem like a good thing to break its current API and documentation as TW> well as what actually works in the Portage tree. +1 on all of that. git-3 is a better name than using -r1. And leave git-2 there for at /least/ a year. There are a LOT of out of tree git-2 users. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
-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_SOURCEDIR21
> EGIT_PROJECT 17
> EGIT_HAS_SUBMODULES 15
> EGIT_COMMIT 12
> EGIT_BOOTSTRAP12
> EGIT_MASTER 7
> EGIT_NOUNPACK 2
> EGIT_STORE_DIR1
> EGIT_NONBARE 1
> EGIT_DIR 1
> EVCS_OFFLINE 0 // these are for make.conf
> EGIT_REPACK 0
> EGIT_PRUNE0
> 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-
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
On 08/28/2013 10:00 AM, Michał Górny wrote: > > What are your thoughts? > Not interested in any of those suggestions. git-2.eclass works fine for me and I will keep using it.
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
On 28 August 2013 16:00, Michał Górny wrote: > Hello, all. > > I think I'm finally ready to put all the breaking awesomeness that was > waiting for the git eclasses. However, I'm wondering what's the best > way of proceeding with it. > > We've just lately finished the git->git-2 eclass migration. The old > eclass is no longer used and is marked for removal in a few days. [...] > However, I would like to do a few breaking changes to simplify > the eclass and its maintenance: [...] > But it's not all removing. There are also a few things I would like to > change/add: [...] > > 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. > > 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? You are planning to do more than trivial changes, so you should make a new eclass (-version). Ebuilds rely on eclass functionality to be stable, so please don't introduce unnecessary breakage. This is another indication that we really need a better mechanism for eclass versioning. But that would deserve it's own separate thread. As for naming, I recommend you do a +1 to avoid confusion, so git-3.eclass, or git-r3.eclass. Again, here it would be good to agree on a convention for everyone to follow. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/28/2013 10:00 AM, Michał Górny wrote:
> 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.
Make that 2622 packages in the gpo.zugaina universe funtoo and gentoo
each 500, and a ton others.
https://xmw.de/tmp/git-2-zugaina.txt
https://xmw.de/tmp/git-2-zugaina-sum.txt
Please don't break the ABI carelessly/intentional, just because you
see these ebuilds as broken by design.
# data generation
wget -r http://data.gpo.zugaina.org/
cd data.gpo.zugaina.org
find . -name "index.html*" -delete
for i in $(ls -1) ; do
for d in $(find ${i} -maxdepth 2 -mindepth 2 -type d) ; do
grep git-2 ${d}/*.ebuild 2>/dev/null >/dev/null && echo ${d}
done
done | tee /tmp/git-2-zugaina.txt
awk '
BEGIN { FS="/" }
{ if ($1 == overlay)
{ c+= 1 }
else
{ print c"\t"overlay ; c=1 ; overlay=$1
}
} END { print c"\t"overlay }
' < /tmp/git-2-zugaina.txt | sort -r -n > /tmp/git-2-zugaina-sum.txt
> The use of API features in *.ebuild maps like the following;
I can run your checks on the dataset, if you provide me the script.
>
> 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_DIR1 EGIT_NONBARE 1 EGIT_DIR
> 1
> EVCS_OFFLINE 0 // these are for make.conf EGIT_REPACK0 EGIT_PRUNE
> 0 EGIT_OPTIONS0
- --
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlIeRvQACgkQknrdDGLu8JDuLgD/T/SRrApytJQAMbN8aIg53Wb9
kohbcTyeUtRxm8lYjFMA/jBkXxyFFcTH1lWuPMS9+RcwseFnI1vo3n13XBfGOIuc
=pNud
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
> What did you use that for? Actually, for "--depth 1" in custom non-maintained-already ebuild ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
Dnia 2013-08-28, o godz. 16:31:36 Tom Wijsman napisał(a): > On Wed, 28 Aug 2013 10:00:07 +0200 > Michał Górny wrote: > > > What are your thoughts? > > If possible, assuming it is not already possible I would like to see > support for checking out multiple repositories; that way the patches > can simply be obtained from a repository instead of having to > explicitly snapshot them for > > Also, please just call it git-3.eclass as it is a major change; any > other form of naming will introduce confusion (eg. -r1 < -2), also we > probably shouldn't change git-2.eclass as even when masked it doesn't > seem like a good thing to break its current API and documentation as > well as what actually works in the Portage tree. More I think about it, I feel like API isn't going to change that much. Rather the effects for end users are going to change. For example, if EGIT_PROJECT stops working that wouldn't cause any real difference to the ebuild. Worst case, there will be a single re-fetch for users. > Regardless, thanks for getting rid of git.eclass and improving it. Just to make it clear, AFAIR scarabeus did most of the work for git-2. I've just took it over so it didn't end up unmaintained but, as you can see, I'd feel better rewriting it since some of the things done inside are just black magic. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
On Wed, 28 Aug 2013 10:00:07 +0200 Michał Górny wrote: > What are your thoughts? If possible, assuming it is not already possible I would like to see support for checking out multiple repositories; that way the patches can simply be obtained from a repository instead of having to explicitly snapshot them for Also, please just call it git-3.eclass as it is a major change; any other form of naming will introduce confusion (eg. -r1 < -2), also we probably shouldn't change git-2.eclass as even when masked it doesn't seem like a good thing to break its current API and documentation as well as what actually works in the Portage tree. Remind that the readers of this list are not the only people who use this eclass; if you just drop it in place or use an older version, some of our users (those using or overlays) are going to be unhappy. It seems better to enumerate all git-2 users and change them to git-3 once it works properly and you have tested them to still work; or, you could ask the maintainers to do the migration next time they work on the package in question. Regardless, thanks for getting rid of git.eclass and improving 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
Dnia 2013-08-28, o godz. 09:01:54
Ian Stakenvicius napisał(a):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 28/08/13 07:30 AM, Vadim A. Misbakh-Soloviov wrote:
> >> 4. Kill EGIT_MASTER (it's more trouble than benefit),
> >
> > Only if EGIT_BRANCH will stay on it's place.
> >
>
> ..and work as well as EGIT_MASTER. I've had issues at times trying to
> get the branch checkout I wanted via setting EGIT_BRANCH, while
> setting it via EGIT_MASTER "just worked". Never looked into why.
And never cared enough to report a bug, did you?
> Also, please ensure that there is a way to override the branch
> checkout on the command line (ie, if EGIT_MASTER is unset in the
> ebuild, using EGIT_MASTER="branch" emerge =foo- is a nice way to
> test something that hasn't been merged into master yet).
There's ${PN}_LIVE_BRANCH variable that is designed exactly for that.
I'd honestly kill it as well but I guess it won't hurt me much if it is
left as-is.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
Dnia 2013-08-28, o godz. 18:30:06 "Vadim A. Misbakh-Soloviov" napisał(a): > > 2. Kill EGIT_HAS_SUBMODULES and autodetect submodules, > > I'm disagreed. Sometimes submodules, that repo suggests is unneded, > since they fetches external package, that specified as RDEP. Then you are using EGIT_HAS_SUBMODULES wrong. It's purpose never were to filter out submodules you don't like. It's only purpose was to switch checkout type because of submodules. > > 3. Kill EGIT_OPTIONS since it limits the possibility of changing eclass > >code, > > :-/ What did you use that for? > > 4. Kill EGIT_MASTER (it's more trouble than benefit), > > Only if EGIT_BRANCH will stay on it's place. Yes, I will put best effort to get EGIT_BRANCH working as it's expected to. The goal is to have just one variable to specify the branch. > > 5. Possibly kill EGIT_PROJECT -- it won't be good enough anymore, > > Why? Because submodules will need additional storedirs. We need to find a good way to choose storedir from EGIT_REPO_URI purely. > > 6. Kill EGIT_NONBARE and support bare checkouts only. Supporting two > >different layouts introduces a lot redundant code. > > AFAIR, that was issues (including shallow clones and so on), that > refuses to use bare repo. I have a good fix that will avoid those issues. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/08/13 07:30 AM, Vadim A. Misbakh-Soloviov wrote: >> 4. Kill EGIT_MASTER (it's more trouble than benefit), > > Only if EGIT_BRANCH will stay on it's place. > ..and work as well as EGIT_MASTER. I've had issues at times trying to get the branch checkout I wanted via setting EGIT_BRANCH, while setting it via EGIT_MASTER "just worked". Never looked into why. Also, please ensure that there is a way to override the branch checkout on the command line (ie, if EGIT_MASTER is unset in the ebuild, using EGIT_MASTER="branch" emerge =foo- is a nice way to test something that hasn't been merged into master yet). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlId9MIACgkQ2ugaI38ACPB4OwD+KGkV/GFRZaa+2MqLidrc1J/0 g4ejIX/oP4K3ey3JoYUA+wYOytTvsU9k4rz+1siL8zCeMnn3eqYMyPHvuUz8T//X =ulxQ -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
> 2. Kill EGIT_HAS_SUBMODULES and autodetect submodules, I'm disagreed. Sometimes submodules, that repo suggests is unneded, since they fetches external package, that specified as RDEP. > > 3. Kill EGIT_OPTIONS since it limits the possibility of changing eclass >code, :-/ > 4. Kill EGIT_MASTER (it's more trouble than benefit), Only if EGIT_BRANCH will stay on it's place. > 5. Possibly kill EGIT_PROJECT -- it won't be good enough anymore, Why? > 6. Kill EGIT_NONBARE and support bare checkouts only. Supporting two >different layouts introduces a lot redundant code. AFAIR, that was issues (including shallow clones and so on), that refuses to use bare repo. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
Michał Górny writes: > I think I'm finally ready to put all the breaking awesomeness that was > waiting for the git eclasses. However, I'm wondering what's the best > way of proceeding with it. TL;DR any futher, but I have few packages which use git-2 eclass and I wouldn't like to have any breakage, so if you're going to break compatibility, do it in git-2-r1 or whatever new version, please. Regards, -- Amadeusz Żołnowski pgpSWifNxR8xL.pgp Description: PGP signature
[gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
Hello, all.
I think I'm finally ready to put all the breaking awesomeness that was
waiting for the git eclasses. However, I'm wondering what's the best
way of proceeding with it.
We've just lately finished the git->git-2 eclass migration. The old
eclass is no longer used and is marked for removal in a few days.
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.
[1]:http://qa-reports.gentoo.org/output/eclass-usage/
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.
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_PROJECT17
EGIT_HAS_SUBMODULES 15
EGIT_COMMIT 12
EGIT_BOOTSTRAP 12
EGIT_MASTER 7
EGIT_NOUNPACK 2
EGIT_STORE_DIR 1
EGIT_NONBARE1
EGIT_DIR1
EVCS_OFFLINE0 // these are for make.conf
EGIT_REPACK 0
EGIT_PRUNE 0
EGIT_OPTIONS0
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.
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?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
