problem: unversioned binary blobs at fixed URLs changing checksums

Jaco Kroon <[email protected]>
Newsgroups gmane.linux.gentoo.devel
Message-ID <[email protected]>
Hi All,

This has been discussed before (IRC conversations).  Various mostly 
working solutions have been proposed.

Point in case: net-misc/asterisk-g729.

The main library downloads are versioned, and not problematic. The 
problem is the astregister and asthostid tools.  Whilst I speak about 
astregister below, everything apply equally to asthostid - except I 
don't recall it ever having suffered the same problem, at least nowhere 
near the same frequency.

The instructions from upstream is to when you need the tool:

wget https://.../register (two variations of this URL for our purposes, 
one for x86 and one for amd4).  We rename to astregister for hopefully 
obvious reasons.

The URL doesn't change from version to version, nor are there versioned 
copies available I could find.  I've engaged with upstream, and whilst 
they understand the problem they don't consider it a problem worth 
solving - and I further suspect that newer versions "fixes" things they 
would rather not leave around to be leveraged in unsavoury ways (which I 
can respect).

Combined with RESTRICT=mirror, the implication is that every time this 
blob gets replaced, asterisk-g729 fails to install/upgrade.

At a minimum I am going to remove the blob from asterisk-g729 package 
itself.

Then there are two options:

1.  Instruct users to follow upstream instructions to obtain and use 
astregister tool.

2.  Put it in a separate (optionally depended on by asterisk-g729) package.

Technically you only ever need astregister in order register the 
relevant licensing.  Whether asterisk-g729 would need to depend on 
astregister is a separate question.  I for one don't like packages that 
don't include everything you need into the installation - which is the 
main reason I'd prefer to avoid 1.

Should I go for option 2, a couple of options:

1.  Should I have asterisk-g729 PDEPEND on astregister?  Or optfeature 
(which IMHO is a mis-feature but we don't have a better way currently).

2.  Would I be permitted to have an "ever stable" rolling version of 
this, ie, whenever I detect (I'll put a cron in place) a change in 
checksum from upstream, I just bump the in-gentoo version by way of 
rename and keep it stable?  Ie, something like: 
SRC="https://.../register -> astregister-${PV}", then git rename 
astregister-YYYYMMDD.ebuild astregister-yyyymmdd.ebuild, pkgdev 
manifest, pkgdev commit

2 here is an obvious QA violation - but compared to the current state of 
affairs for this specific problem I reckon getting an exemption for this 
would (and should) be preferred over the package being uninstallable for 
a month at a time, and avoiding having to rope in other devs for 
emergency stables every so often would help.

This is a niche package, I can't imagine it having too many users.  Then 
again ... the bugs that Gentoo users find in asterisk I might be 
surprised at the number of users.

Kind regards,
Jaco
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.