* was (Fwd: Re: binutils-2.20.1a replaced by 2.20.1 and so 2.21.1a?): symlink old tarball name to new one
@ 2011-09-01 9:51 Abdoulaye Walsimou GAYE
2011-09-10 22:28 ` Yann E. MORIN
0 siblings, 1 reply; 6+ messages in thread
From: Abdoulaye Walsimou GAYE @ 2011-09-01 9:51 UTC (permalink / raw)
To: gdb
Dear all,
How about to have the same simlinks to new gdb tarballs name?
Thanks,
AWG
-------- Original Message --------
Subject: Re: binutils-2.20.1a replaced by 2.20.1 and so 2.21.1a?
Date: Thu, 1 Sep 2011 10:43:20 +0200
From: Tristan Gingold <gingold@adacore.com>
To: Abdoulaye Walsimou GAYE <awg@embtoolkit.org>
CC: Steffen Dettmer <steffen.dettmer@googlemail.com>, binutils@sourceware.org
On Aug 31, 2011, at 9:23 PM, Abdoulaye Walsimou GAYE wrote:
> On 08/30/2011 05:36 PM, Tristan Gingold wrote:
>> On Aug 30, 2011, at 5:32 PM, Steffen Dettmer wrote:
>>
>>>> This was a license issue raised by the FSF: some files were
>>>> derived from cgen files, but these cgen files weren't included
>>>> in the tarballs. We were asked by the FSF to repackage all the
>>>> incomplete tarballs.
>>> Thank you for your quick reply.
>>>
>>> The issue itself is interesting. Sounds like much effort and may
>>> even require undesired things like modifying release tags...
>>> I though it would be sufficient to publish GPLed files, not that a
>>> special form could be required (and I had assumed it had been
>>> sufficient to put them on some public server or even just to some
>>> CVS repository reabable by the public).
>> Yes, the workload is not minimal, but this was the FSF decision.
>>
>> Tristan.
>
> This kind of URL change is a serial killer for automatic build system/script already shipped.
> Is it possible to have simlinks like 'oldername'->'newname'
> (as for example binutils-2.21.1a.tar.bz2 tarball will actually contain binutils-2.21.1)?
Yes, good idea.
Done for 2.16 to 2.21.1.
Tristan.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: symlink old tarball name to new one 2011-09-01 9:51 was (Fwd: Re: binutils-2.20.1a replaced by 2.20.1 and so 2.21.1a?): symlink old tarball name to new one Abdoulaye Walsimou GAYE @ 2011-09-10 22:28 ` Yann E. MORIN 2011-09-10 23:00 ` Matt Rice 2011-09-12 16:40 ` Joel Brobecker 0 siblings, 2 replies; 6+ messages in thread From: Yann E. MORIN @ 2011-09-10 22:28 UTC (permalink / raw) To: gdb; +Cc: Abdoulaye Walsimou GAYE All, Recently, the gdb release tarballs were re-released to fix the GPL compliance issue with the cgen files. That's fine so far. What's problematic is that the old tarballs were deleted, and new tarballs were cretaed with an alternate name. This poses two problems. First, autobuilders such as crosstool-NG or buildroot (but also many others) that need to download the gdb sources now choke on the missing /legacy/ versions. This is an issue, because existing releases of these tools are broken. Second, the new tarballs were created with an 'a' appended to the version string, making for example '7.1' being called in fact '7.1a', but the directory within those tarballs are still named after the real version, in this case '7.1'. So it is not possible to easily derive the tarball name from the version string, and then the directory name from the tarball name. Either we use an 'a' at the end of the version, and we can get the tarball but we don't know the directory name; or we ignore the 'a', so we know the directory name, but can't find the tarball. On Thursday 01 September 2011 11:51:37 Abdoulaye Walsimou GAYE wrote: > How about to have the same simlinks to new gdb tarballs name? I second Abdoulaye's suggestion. As 'ratmice' said on IRC, this has a drawback for those tools that do check the tarballs using md5 (or sha1...). Using signatures is not an issue. But not all tools do use md5 (or even sigs). Providing legacy symlinks that point back to the new releases (for example gdb-7.1.tar.bz2 points to gdb-7.1a.tar.bz2, ditto for .sig) would be a great help for those projects. For information, the binutils guys did agree to have those /legacy/ symlinks put in place for binutils (which was Abdoulaye's initial forwarded message): http://sourceware.org/ml/binutils/2011-09/msg00000.html Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: symlink old tarball name to new one 2011-09-10 22:28 ` Yann E. MORIN @ 2011-09-10 23:00 ` Matt Rice 2011-09-10 23:27 ` Yann E. MORIN 2011-09-12 16:40 ` Joel Brobecker 1 sibling, 1 reply; 6+ messages in thread From: Matt Rice @ 2011-09-10 23:00 UTC (permalink / raw) To: Yann E. MORIN; +Cc: gdb, Abdoulaye Walsimou GAYE On Sat, Sep 10, 2011 at 3:28 PM, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote: > As 'ratmice' said on IRC, this has a drawback for those tools that do check > the tarballs using md5 (or sha1...). Using signatures is not an issue. > But not all tools do use md5 (or even sigs). FWIW, I'm not sure that this is much of an argument for tools that do check using sums, they have only one option... They must change their build script regardless of the symlink. further, the gdb ftp site doesn't host sums, so theres really nothing to compare it to otherwise. (unless people are in the habit of checking the gpg sig, making a sum and then checking that in which case, they are in the 'they must change their script dept.). anyhow, its something to consider and leaves a bitter taste in my mouth, but i'm not objecting, it probably fixes more issues than it causes. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: symlink old tarball name to new one 2011-09-10 23:00 ` Matt Rice @ 2011-09-10 23:27 ` Yann E. MORIN 0 siblings, 0 replies; 6+ messages in thread From: Yann E. MORIN @ 2011-09-10 23:27 UTC (permalink / raw) To: gdb; +Cc: Matt Rice Matt, All, On Sunday 11 September 2011 01:00:36 Matt Rice wrote: > On Sat, Sep 10, 2011 at 3:28 PM, Yann E. MORIN > <yann.morin.1998@anciens.enib.fr> wrote: > > > As 'ratmice' said on IRC, this has a drawback for those tools that do check > > the tarballs using md5 (or sha1...). Using signatures is not an issue. > > But not all tools do use md5 (or even sigs). > > FWIW, I'm not sure that this is much of an argument for tools that do > check using sums, > they have only one option... They must change their build script > regardless of the symlink. > > further, the gdb ftp site doesn't host sums, so theres really nothing > to compare it to otherwise. (unless people are in the habit of > checking the gpg sig, making a sum and then checking that in which > case, they are in the 'they must change their script dept.). Yes, indeed. For those checking against embedded sums, there are few options, but to fix their scripts. But for those that do not use sums (and might or not check the sigs), providing the symlinks is a life-saver for all the already-released versions of those tools. Fact is, even if those projects already have fixes (crosstool-NG has, buildroot should follow suite when I'm done pushing the change), it might not be an option for users to upgrade for various reasons, especially those in corporate environments where versions are written in stone, and an upgrade requires much more than simply an upstream version string change. > anyhow, its something to consider and leaves a bitter taste in my > mouth, but i'm not objecting, it probably fixes more issues than it > causes. Yes, it does fixes more than it breaks. Those using sums are already and irremediably broken. Those not using sums would be fixed with the symlinks. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: symlink old tarball name to new one 2011-09-10 22:28 ` Yann E. MORIN 2011-09-10 23:00 ` Matt Rice @ 2011-09-12 16:40 ` Joel Brobecker 2011-09-13 14:15 ` Yann E. MORIN 1 sibling, 1 reply; 6+ messages in thread From: Joel Brobecker @ 2011-09-12 16:40 UTC (permalink / raw) To: Yann E. MORIN; +Cc: gdb, Abdoulaye Walsimou GAYE > First, autobuilders such as crosstool-NG or buildroot (but also many > others) that need to download the gdb sources now choke on the missing > /legacy/ versions. This is an issue, because existing releases of > these tools are broken. We're very sorry about the inconvenience. I discussed the suggestion of providing symlinks with RMS, and he said that scripts should be fixed instead. I am only the messenger, so please do not shoot me. I tend to agree with RMS, but I admit I do not know about all the scripts out there, and the amount of work that this renaming has created. > Second, the new tarballs were created with an 'a' appended to the > version string, making for example '7.1' being called in fact '7.1a', > but the directory within those tarballs are still named after the real > version, in this case '7.1'. So it is not possible to easily derive > the tarball name from the version string, and then the directory name > from the tarball name. This is intentional. This is the exact same GDB version, we just fixed the sources. The 'a' in the package name is there to indicate that the problem found in those sources has been addressed. Note that we provide an md5.sum file on the sourceware.org FTP. -- Joel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: symlink old tarball name to new one 2011-09-12 16:40 ` Joel Brobecker @ 2011-09-13 14:15 ` Yann E. MORIN 0 siblings, 0 replies; 6+ messages in thread From: Yann E. MORIN @ 2011-09-13 14:15 UTC (permalink / raw) To: gdb; +Cc: Joel Brobecker Joel, All, On Monday 12 September 2011 18:40:29 Joel Brobecker wrote: > > First, autobuilders such as crosstool-NG or buildroot (but also many > > others) that need to download the gdb sources now choke on the missing > > /legacy/ versions. This is an issue, because existing releases of > > these tools are broken. > > We're very sorry about the inconvenience. I discussed the suggestion > of providing symlinks with RMS, and he said that scripts should be > fixed instead. The development trees of affected projects have been easily fixed (or will soon be fixed) to use the new names. What poses a problem is that released versions of these projects still use the now-legacy URLs do download gdb. This means that, until these projects do a new release, they are completely broken. > I am only the messenger, so please do not shoot me. Hehe, of course not! Plus, we probably are on two opposite shores of an ocean, so that'd be a long shot! :-) > I tend to agree with RMS, but I admit I do not know about all the > scripts out there, and the amount of work that this renaming has > created. What is the rationale for not providing legacy symlinks, when there are good reasons exposed previously that would highly benefit? Of course, I can understand that there are greater reasons not to provide those symlinks, but I really like to understand... ;-) What's important in my eyes is that the GPL issue has been fixed, and that getting the sources will get you the full sources, and a symlink would just guarantee that; plus, also symlinking the .sig would also allow for the verification, as it only signs the content. > > Second, the new tarballs were created with an 'a' appended to the > > version string, making for example '7.1' being called in fact '7.1a', > > but the directory within those tarballs are still named after the real > > version, in this case '7.1'. So it is not possible to easily derive > > the tarball name from the version string, and then the directory name > > from the tarball name. > > This is intentional. This is the exact same GDB version, we just fixed > the sources. The 'a' in the package name is there to indicate that > the problem found in those sources has been addressed. And because the content of the tarball for X.Ya is not exactly the same as for X.Y, that could be interpreted as being a new version... And again, that breaks auto-builders that used to rely on the assumption that: tarball_basename == dirname > Note that we provide an md5.sum file on the sourceware.org FTP. Which is not the main distribution channel (it's official, but not main) and is lacking the signature files, which are present on ftp.gnu.org. Anyway, thanks for [hb]earing me! ;-) Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-13 14:15 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-01 9:51 was (Fwd: Re: binutils-2.20.1a replaced by 2.20.1 and so 2.21.1a?): symlink old tarball name to new one Abdoulaye Walsimou GAYE 2011-09-10 22:28 ` Yann E. MORIN 2011-09-10 23:00 ` Matt Rice 2011-09-10 23:27 ` Yann E. MORIN 2011-09-12 16:40 ` Joel Brobecker 2011-09-13 14:15 ` Yann E. MORIN
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).