[gentoo-dev] Last rites: app-text/htmltidy
# Patrice Clement (21 Nov 2015) # Upstream dead + superseded by app-text/tidy-html5. # Masked for removal in 30 days. See bug #564884. app-text/htmltidy -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 6 portage is out!
Hi, On Wed, 18 Nov 2015 07:01:21 -0500 Rich Freeman wrote: > On Wed, Nov 18, 2015 at 6:12 AM, Alexander Berntsen > wrote: > > When I do QA in projects I'm involved with (at least outside of > > Gentoo), we don't do it live on end-user systems. I'll leave the > > details as an exercise for the Gentoo developer. > > > > People who run ~arch are not really end-users - they're contributors > who have volunteered to test packages. I strongly disagree with you. We do not use stable even at enterprise grade production systems and HPC setups. Stable is just too freaking old in order to be usable for our purposes, not to mention that it lacks many packages at all. We tried stable several times, it just freaks out admins (including myself) too badly or results in horrible mess of stable and unstable which is less stable that unstable setups. I do not use stable at workstations and personal setups as well. Nevertheless I consider stable useful as stabilization process gives more testing for packages (and some fixes are forward ported to unstable versions). Of course I understand that there are people using it and I try to support stable packages as well, but these versions are mostly a burden and I can't really understand stable users. Best regards, Andrew Savchenko pgpVC4orUTzSl.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 6 portage is out!
On Sat, Nov 21, 2015 at 1:51 PM, Andrew Savchenko wrote: > > On Wed, 18 Nov 2015 07:01:21 -0500 Rich Freeman wrote: >> On Wed, Nov 18, 2015 at 6:12 AM, Alexander Berntsen >> wrote: >> > When I do QA in projects I'm involved with (at least outside of >> > Gentoo), we don't do it live on end-user systems. I'll leave the >> > details as an exercise for the Gentoo developer. >> > >> >> People who run ~arch are not really end-users - they're contributors >> who have volunteered to test packages. > > I strongly disagree with you. We do not use stable even at > enterprise grade production systems and HPC setups. Stable is just > too freaking old in order to be usable for our purposes, not to > mention that it lacks many packages at all. We tried stable > several times, it just freaks out admins (including myself) too > badly or results in horrible mess of stable and unstable which is > less stable that unstable setups. I do not use stable at > workstations and personal setups as well. Interesting. I've had the opposite experience, and don't run ~arch except for testing purposes. I don't hesitate to keyword packages when necessary, and file bugs for their stabilization if appropriate. Also, if you're doing something like HPC then you're probably focused on a specific application, with your own QA system, so Gentoo's QA doesn't really impact you much anyway as your own regression test is going to catch issues. I'm not nearly that formal but I've containerized almost all my services because I don't like relying on Gentoo's QA. If I update my mariadb container I just make sure that mariadb is working, and revert it if not. If it happens to contain a broken ssh client it doesn't concern me at all, since I don't use that container for ssh. Of course, the downside of this is that I end up updating a lot of hosts, all for personal use. > Of course I understand that there are people > using it and I try to support stable packages as well, but these > versions are mostly a burden and I can't really understand stable > users. Well, to be fair it seems like most Gentoo developers consider half the tree a burden (that would be the "other" half). We all have our itches that we're trying to scratch. As long as everybody follows the policies the results end up working out reasonably well for everybody. Some of us barely test ~arch at all, and others barely test stable at all, and it seems that for the most part things work out. In any case, the purpose of ~arch is testing, and is not intended to be a stable experience, even if it often ends up being that way (which is certainly nothing to complain about). If we added another layer of testing above ~arch, all we'd see happen is that everybody who runs ~arch today would just switch to that, since it would essentially be the same thing, and ~arch wouldn't really serve any purpose at all. If the purpose of ~arch isn't testing, then why have it at all? But, like I said, if somebody wants to volunteer to do a barrage of QA tests on portage, by all means do so. It will only make life better for everybody. I just don't see any reason to bar the portage authors from introducing a version if they consider it suitable for testing. -- Rich
[gentoo-dev] [EAPI 7] The future goals for PORTDIR, ECLASSDIR and... LICENSEDIR?
Hello, everyone.
Currently PMS defines two variables that are being repeatedly abused to
access repository data in unpredictable and breaking manners -- PORTDIR
and ECLASSDIR. They both reference only so-called 'master
repository', are permitted in source builds and src_* phases only.
For quite some time, QA is monitoring their use and repeatedly
reporting abuses and spec violations. I'd like to run a joint QA & PMS
team effort in cleaning up those variables for sane multi-repository
support or banning them altogether. For this reason, I would like to
know your opinion.
Licenses [1]
So far, the most common use of ${PORTDIR} was to access the licenses
subdirectory. That has a number of issues -- most importantly, it fails
when the license is provided by another repository. It is also unusable
in binary packages.
So far I see two major possibilities here. We can either decide that:
a. ebuilds don't need to access licenses directly and if they do,
the licenses are usually included in distfiles or can be obtained
independently of ebuild tree, or
b. we provide a proper, safe mechanism for obtaining licenses that
works with multiple repositories and binary packages. In particular,
I was thinking of establishing a LICENSEDIR that would contain copies
or symlinks to all needed licenses, both in source and binary installs.
Few relevant current bugs:
- sci-visualization/veusz: replaces bundled license with PORTDIR
symlink, which will fail if repository is moved or when using binary
packages [2],
- sci-biology/foldingathome: tries to reference the license
in pkg_setup(), while PORTDIR is valid only in src_* [3],
- sys-block/tw_cli: copies license into install. The license is not
included in tarball, yet we have different opinions whether copying
it is necessary or not [4].
Eclasses [5]
The next thing is ECLASSDIR, sometimes disguised as equivalent
${PORTDIR}/eclass. It is used only by a single developer, for two
reasons. One is to create eclass-manpages whose ebuild is a huge hack
relying on random deprecated Portage variables anyway, so not worth
noting. The other is to access a huge collection of patches (over 100
files) which are stored in eclass/ELT-patches and not ever used on most
of Gentoo systems.
We've considered different options on how to make ECLASSDIR sane and so
far seems there's no real way of doing it while keeping the ELT-patches
thing working (the way suggested for licenses won't work, for example).
So for less sane solutions, again we have two:
A. ban ECLASSDIR completely, and move ELT-patches to a dedicated
package [6]. This way, it could be cleanly managed, versioned
and filtered to install only files relevant to user's system (i.e. not
for all potential prefixes we support), and libtool.eclass can simply
DEPEND on it. Furthermore, a lot of the code could be moved to
a reusable external patcher tool.
B. Restrict ECLASSDIR to be available only in global scope of
eclasses (i.e. while sourcing them), and set it to the repository from
which eclass is sourced. This is ugly, barely predictable but should
work. Well, as long as you copy the whole ELT-patches structure along
with libtool.eclass.
PORTDIR [7]
---
Almost all uses of PORTDIR are covered by the two above categories.
The only remaining use is games-mods.eclass using it to read header.txt
file from the repository [8]. Which in fact could be trivially replaced
if games team members had a little different attitude towards QA but
I guess that's not my problem.
Therefore, I think that if both of the above issues are solved either
way, PORTDIR should be banned completely. Until then, we'd like it to
be QA-deprecated and discouraged from being used unless absolutely
necessary.
What are your thoughts?
[1]:https://bugs.gentoo.org/show_bug.cgi?id=566412
[2]:https://bugs.gentoo.org/show_bug.cgi?id=341653
[3]:https://bugs.gentoo.org/show_bug.cgi?id=566402
[4]:https://bugs.gentoo.org/show_bug.cgi?id=566416
[5]:https://bugs.gentoo.org/show_bug.cgi?id=373351
[6]:https://bugs.gentoo.org/show_bug.cgi?id=566424
[7]:https://bugs.gentoo.org/show_bug.cgi?id=373349
[8]:https://bugs.gentoo.org/show_bug.cgi?id=416739
--
Best regards,
Michał Górny
Re: [gentoo-dev] [EAPI 7] The future goals for PORTDIR, ECLASSDIR and... LICENSEDIR?
Probably not the ideal solution given that you seem to prefer removal of such
variables, but a REPODIR variable which is set to the directory where the repo
is (basically making PORTDIR dynamic and setting it on a per package basis)
could enable developers to reference their repo when needed, allowing variable
use in a multi repo system. Additionally, if that idea is liked, I think an
array of the repos masters and/or their dirs (or some functions to access that
information) could also be useful. Like get_masters and get_repo_dir functions.
Just some ideas and I have no real attachments, but just figured I would
brainstorm and put them out there.
On November 21, 2015 4:36:57 PM EST, "Michał Górny" wrote:
>Hello, everyone.
>
>Currently PMS defines two variables that are being repeatedly abused to
>access repository data in unpredictable and breaking manners -- PORTDIR
>and ECLASSDIR. They both reference only so-called 'master
>repository', are permitted in source builds and src_* phases only.
>
>For quite some time, QA is monitoring their use and repeatedly
>reporting abuses and spec violations. I'd like to run a joint QA & PMS
>team effort in cleaning up those variables for sane multi-repository
>support or banning them altogether. For this reason, I would like to
>know your opinion.
>
>
>Licenses [1]
>
>
>So far, the most common use of ${PORTDIR} was to access the licenses
>subdirectory. That has a number of issues -- most importantly, it fails
>when the license is provided by another repository. It is also unusable
>in binary packages.
>
>So far I see two major possibilities here. We can either decide that:
>
>a. ebuilds don't need to access licenses directly and if they do,
>the licenses are usually included in distfiles or can be obtained
>independently of ebuild tree, or
>
>b. we provide a proper, safe mechanism for obtaining licenses that
>works with multiple repositories and binary packages. In particular,
>I was thinking of establishing a LICENSEDIR that would contain copies
>or symlinks to all needed licenses, both in source and binary installs.
>
>Few relevant current bugs:
>
>- sci-visualization/veusz: replaces bundled license with PORTDIR
> symlink, which will fail if repository is moved or when using binary
> packages [2],
>
>- sci-biology/foldingathome: tries to reference the license
> in pkg_setup(), while PORTDIR is valid only in src_* [3],
>
>- sys-block/tw_cli: copies license into install. The license is not
> included in tarball, yet we have different opinions whether copying
> it is necessary or not [4].
>
>
>Eclasses [5]
>
>
>The next thing is ECLASSDIR, sometimes disguised as equivalent
>${PORTDIR}/eclass. It is used only by a single developer, for two
>reasons. One is to create eclass-manpages whose ebuild is a huge hack
>relying on random deprecated Portage variables anyway, so not worth
>noting. The other is to access a huge collection of patches (over 100
>files) which are stored in eclass/ELT-patches and not ever used on most
>of Gentoo systems.
>
>We've considered different options on how to make ECLASSDIR sane and so
>far seems there's no real way of doing it while keeping the ELT-patches
>thing working (the way suggested for licenses won't work, for example).
>So for less sane solutions, again we have two:
>
>A. ban ECLASSDIR completely, and move ELT-patches to a dedicated
>package [6]. This way, it could be cleanly managed, versioned
>and filtered to install only files relevant to user's system (i.e. not
>for all potential prefixes we support), and libtool.eclass can simply
>DEPEND on it. Furthermore, a lot of the code could be moved to
>a reusable external patcher tool.
>
>B. Restrict ECLASSDIR to be available only in global scope of
>eclasses (i.e. while sourcing them), and set it to the repository from
>which eclass is sourced. This is ugly, barely predictable but should
>work. Well, as long as you copy the whole ELT-patches structure along
>with libtool.eclass.
>
>
>PORTDIR [7]
>---
>
>Almost all uses of PORTDIR are covered by the two above categories.
>The only remaining use is games-mods.eclass using it to read header.txt
>file from the repository [8]. Which in fact could be trivially replaced
>if games team members had a little different attitude towards QA but
>I guess that's not my problem.
>
>Therefore, I think that if both of the above issues are solved either
>way, PORTDIR should be banned completely. Until then, we'd like it to
>be QA-deprecated and discouraged from being used unless absolutely
>necessary.
>
>
>What are your thoughts?
>
>
>[1]:https://bugs.gentoo.org/show_bug.cgi?id=566412
>[2]:https://bugs.gentoo.org/show_bug.cgi?id=341653
>[3]:https://bugs.gentoo.org/show_bug.cgi?id=566402
>[4]:https://bugs.gentoo.org/show_bug.cgi?id=566416
>[5]:https://bugs.gentoo.org/show_bug.cgi?id=373351
>[6]:https://bugs.gentoo.org/show_bug.cgi?id=566424
>[7]:https://bugs.gentoo.org/show_bug.cgi?id=373349
>[8]:https://bugs.ge
Re: [gentoo-dev] [EAPI 7] The future goals for PORTDIR, ECLASSDIR and... LICENSEDIR?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/11/15 06:29 PM, NP-Hardass wrote: > Probably not the ideal solution given that you seem to prefer > removal of such variables, but a REPODIR variable which is set to > the directory where the repo is (basically making PORTDIR dynamic > and setting it on a per package basis) could enable developers > to reference their repo when needed, allowing variable use in a > multi repo system. Additionally, if that idea is liked, I think > an array of the repos masters and/or their dirs (or some > functions to access that information) could also be useful. Like > get_masters and get_repo_dir functions. > - From your description here REPODIR would only point to the current repo, so for licence-file access when the license is in the main gentoo repo, but the current repo is an overlay, it would still fail. Similar cases could occur for eclasses, especially since 'masters' in repo metadata allows multiple repos to be chained. All told, I think i'm in favour of banning the variables, and potentially providing getter functions that would output the path of these files if they need to be accessed -- '$(get_eclasspath [name])' or $(get_licensepath [name]) or the like. I don't know if these could be implemented in-eclass or if they would be something that would have to be added to EAPI7..? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlZRAu4ACgkQAJxUfCtlWe1r4wEA3bnt0LtExuJCFTFMzZfzoTgl q+T0eEPvKw0HK3De9rsA/iZZlZ0VKBTErx7mXk4YjiykN9Ruk/ZswkDDSGWM29IW =JEGh -END PGP SIGNATURE-
