[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic token kinds
From: |
Frank Heckenbach |
Subject: |
Re: Dynamic token kinds |
Date: |
Sun, 23 Dec 2018 21:27:10 +0100 |
Akim Demaille wrote:
> [gnulib]
> > I never liked that
> > design, and apparently it's now causing me actual problems by
> > breaking the simple download and vastly increasing the clone size
> > (AFAICS, most of it is downloading the gnulib history which I don't
> > care a tiny bit about, especially not when just trying to build
> > Bison).
>
> I can understand this. However, this is the only model I can
> see that really allows the maintainer of a package to be able
> to use the latest version of the library, in case it addresses
> a recent portability issue.
Does this happen so often? Otherwise, why not -- just like with any
other library -- let affected users upgrade their library once
instead of having to rebuild all packages that use it? IOW, why
should the maintainer of a package have to care about the library
version, as long as it satisfies her package's requirements, i.e.
specify a minimum version as required by the package?
> It's not too inconvenient to use
> as a user of git, and it's completely invisible for the end
> user (i.e., users of the tarballs).
Mostly ... ;)
> > Perhaps what I can do (as I slight kludge) for future patches is to
> [...]
>
> The easiest, by far, would be for me to provide you with a
> viable tarball :(
That's a bit unpractical for every small change.
Regards,
Frank
- Re: Porting to typed C++ parser (was: Dynamic token kinds), (continued)
- Re: Dynamic token kinds, Akim Demaille, 2018/12/19
- Re: Dynamic token kinds, Frank Heckenbach, 2018/12/21
- Re: Dynamic token kinds, Akim Demaille, 2018/12/22
- Re: Dynamic token kinds, Frank Heckenbach, 2018/12/22
- Re: Dynamic token kinds, Akim Demaille, 2018/12/23
- Re: Dynamic token kinds, Frank Heckenbach, 2018/12/23
- Re: Dynamic token kinds, Akim Demaille, 2018/12/23
- Re: Dynamic token kinds,
Frank Heckenbach <=