[xiphos-devel] 4.2.0 tagged and pushed

Caleb Maclennan caleb at alerque.com
Fri May 8 04:07:14 MST 2020


And before anybody chimes in, yes I'm aware there are yet more namespaces
already floating around on launchpad. There is a "crosswire-misc" project,
a "~pkg-crosswire-devel" team, and half a dozen "xiphos-something" projects
users have spawned building their own PPAs. I would ignore all the bits
except the ones I mentioned before and gradually hope to
cleanup/consolidate/obsolete them in favor of clearly named canonical
namespaces for the various resources.

I also forgot to mention my third recommendation: the least disruptive
solution(s) possible are to use the existing "xiphos-devel" or
"pkgcrosswire" team team space and add a new PPA (either "xiphos-devel/ppa"
or "pkgcrosswire/xiphos" and setup packaging there. No renames to existing
launchpad stuff, just a new new fresh PPA and leave the existing archaic
Crosswire PPAs to be cleaned up later.

On Fri, May 8, 2020 at 1:50 PM Caleb Maclennan <caleb at alerque.com> wrote:

> A couple days ago I updated the Arch Linux AUR package build to 4.2.0 (now
> 4.2.1) and also posted pre-compiled packages to my user repository, see
> https://aur.archlinux.org/packages/xiphos. I'm also working on getting
> Xiphos included in the default Arch [community] repository, but it looks
> like that is probably going to get held up until the issue with GTKHTML is
> resolved. Having deprecated that monstrosity from [community] to AUR some
> time back nobody wants to see it moving the other way (myself included). If
> and when that gets removed as a dependency it's quite likely we'll be able
> to get Xiphos into the mainline repository.
>
> There are now just a few distros to go, see
> https://repology.org/project/xiphos/versions!
>
> *On the subject of Ubuntu packaging I*'ve been granted access to most of
> the Xiphos related shenanigans on Launchpad. I'm sorry for all ya'll Ubuntu
> folks because wow is Launchpad a disaster. Through no particular fault even
> of the original configuration (which took the shotgun approach of
> registering every project and team name variant possible) and really just a
> function of how bizarre Launchpad's namespacing is, there doesn't seem to
> be what I would consider an ideal way to name an official Xiphos PPA. So
> request for comment on the options as I see them...
>
> For background Launchpad has two basic namespaces: projects and users.
> Users can, pretty much interchangeably, be individuals or teams. Each has a
> different URL namespace (projects are /<project> and users/teams are
> /~<user>). So far so good. The trouble is that even though they are
> different types and have different namespaces, Launchpad cross checks users
> against projects so you cannot register a team name with the same name as a
> project. Weird (especially since the error messages don't indicate this is
> the issue, it just says another "user" is registered with that name even
> when the offending conflict is a project). Even that might have been okay,
> but Launchpad does not allow projects to have PPAs, only users/teams can
> host PPAs.
>
> 1. There is a project called "xiphos". This is logical enough, but it
> means we can't host a PPA called "xiphos/ppa", it has to be something else.
> 2. There is a team registered called "xiphos-devel". This makes (some)
> sense as a team name, but less sense as a PPA namespace for official
> builds. We could put a PPA under this namespace called "xiphos-devel/ppa"
> or "xiphos-devel/xiphos" or something like that (I think the former is more
> Ubuntu ideomatic).
> 3. There is (very unfortunately and completely uselessly) a _project_
> called "crosswire". This should have been registered as team not a project,
> but I'm not sure we can fix that. Maybe we can ... but it would involve
> some renames.
> 4. Probably born out of the the conflict with 3, there is a team called
> "pkgcrosswire" that hosts PPAs. One of these is the default stable channel
> PPA called "pkgcrosswire/ppa". This has Xiphos already, albeit in a very
> dated form (circa 2012). Everything else in there is dated too.
>
> My personal recommendation is to attempt to ⓐ rename the "crosswire"
> project out of the way, ⓑ rename the "pkgcrosswire" team as "crosswire", ⓒ
> add a new PPA in this namespace called "crosswire/xiphos", ⓓ include the
> bare minimum Xiphos + direct dependencies, and finally ⓔ mark that new PPA
> as a dependency for the default "crosswire/ppa" so that Xiphos is included
> there too. Code for the Debian packaging rules could logically go under the
> existing "xiphos" project, and the "xiphos-devel" team would be used as is
> just for permissions management. I think this would be the cleanest outcome
> overall, but it is dependent on 3 things. Launchpad has to support these
> renames without reserving the old namespaces. Also it means renaming the
> possible in-use pkgcrosswire/ppa to crosswire/ppa. I doubt this is a
> serious issue considering the newest packages in there are from 2014, with
> most being older than that. Lastly I/we need more access to the "crosswire"
> project. I am am part of the team that controls it now but not an
> admin/owner so I can't rename it.
>
> If that option doesn't sound good to people my next bid would be to
> consider renaming the "xiphos-devel" team to something more end-user
> friendly (maybe "xiphos-project" or "xiphos-packages" or something like
> that) and opening a PPA in there, so the address people would use would be
> "ppa:xiphos-project/ppa" or similar. The resulting PPA could still be
> marked as included in "pkgcrosswire/ppa" eventually.
> Any other suggestions? Am I missing important considerations here?
>
> Caleb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20200508/02a9c436/attachment-0001.html>


More information about the xiphos-devel mailing list