[aur-general] btrfs-progs packages
Hi, I've submitted two new btrfs packages to the AUR: btrfs-progs-unstable-integration [0] and btrfs-progs-unstable-integration-git [1], and I'd like opinions on the state of things: a) should btrfs-progs-git [2] should be merged with btrfs-progs-unstable-integration-git, given that the latter is more true to it's name as a -git package, and the former is more of a lagging stable version of the "non-git" integration branch or b) should the non-git, btrfs-progs-unstable-integration package be dropped in favour of the more stable btrfs-progs-git package or c) should all three packages remain or d) should the unstables be merged into one PKGBUILD with the option to let the user choose between "stable" and "next" by setting a variable in it? or e) something else? Personally, I'm happy maintaining all three packages, but I'm aware that I have just tripled the number of btrfs-progs packages in the AUR, which may cause some confusion with some users, and may be considered littering the AUR. Some further information which may be useful: btrfs-progs-git = stable, but stale (no commits since July 5th) btrfs-progs-unstable-integration = unstable, but known to build, snapshot of the integration-next (git) branch btrfs-progs-unstable-integration-git = most unstable, actively committed to, may not always build Thanks. [0] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration/ [1] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/ [2] https://aur.archlinux.org/packages/btrfs-progs-git/
On Mon, Sep 16, 2013 at 5:35 PM, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
Hi, I've submitted two new btrfs packages to the AUR: btrfs-progs-unstable-integration [0] and btrfs-progs-unstable-integration-git [1], and I'd like opinions on the state of things:
a) should btrfs-progs-git [2] should be merged with btrfs-progs-unstable-integration-git, given that the latter is more true to it's name as a -git package, and the former is more of a lagging stable version of the "non-git" integration branch
or
b) should the non-git, btrfs-progs-unstable-integration package be dropped in favour of the more stable btrfs-progs-git package
or
c) should all three packages remain
or
d) should the unstables be merged into one PKGBUILD with the option to let the user choose between "stable" and "next" by setting a variable in it?
or
e) something else?
Personally, I'm happy maintaining all three packages, but I'm aware that I have just tripled the number of btrfs-progs packages in the AUR, which may cause some confusion with some users, and may be considered littering the AUR.
Some further information which may be useful:
btrfs-progs-git = stable, but stale (no commits since July 5th) btrfs-progs-unstable-integration = unstable, but known to build, snapshot of the integration-next (git) branch btrfs-progs-unstable-integration-git = most unstable, actively committed to, may not always build
Thanks.
[0] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration/ [1] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/ [2] https://aur.archlinux.org/packages/btrfs-progs-git/
I don't think we need more than a git package (with Mason tree). Our official package is already a git snapshot and Tom asked[1] to change that. [1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg26611.html -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
As it stands, the new testing/btrfs-progs is building the same tools as the btrfs-progs-git PKGBUILD (albeit with !staticlibs), extra/btrfs-progs is still quite behind. Once the testing package hits extra, btrfs-progs-git will be redundant (at least until Chris pulls in more commits). I guess the worth of btrfs-progs-git depends on how often Tom is planning on updating the commit ref in the official PKGBUILD and/or how often Chris pulls in changes to his tree. On 17 September 2013 10:55, Sébastien Luttringer <seblu@seblu.net> wrote:
On Mon, Sep 16, 2013 at 5:35 PM, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
Hi, I've submitted two new btrfs packages to the AUR: btrfs-progs-unstable-integration [0] and btrfs-progs-unstable-integration-git [1], and I'd like opinions on the state of things:
a) should btrfs-progs-git [2] should be merged with btrfs-progs-unstable-integration-git, given that the latter is more true to it's name as a -git package, and the former is more of a lagging stable version of the "non-git" integration branch
or
b) should the non-git, btrfs-progs-unstable-integration package be dropped in favour of the more stable btrfs-progs-git package
or
c) should all three packages remain
or
d) should the unstables be merged into one PKGBUILD with the option to let the user choose between "stable" and "next" by setting a variable in it?
or
e) something else?
Personally, I'm happy maintaining all three packages, but I'm aware that I have just tripled the number of btrfs-progs packages in the AUR, which may cause some confusion with some users, and may be considered littering the AUR.
Some further information which may be useful:
btrfs-progs-git = stable, but stale (no commits since July 5th) btrfs-progs-unstable-integration = unstable, but known to build, snapshot of the integration-next (git) branch btrfs-progs-unstable-integration-git = most unstable, actively committed to, may not always build
Thanks.
[0] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration/ [1] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/ [2] https://aur.archlinux.org/packages/btrfs-progs-git/
I don't think we need more than a git package (with Mason tree). Our official package is already a git snapshot and Tom asked[1] to change that.
[1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg26611.html
-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On Tue, Sep 17, 2013 at 1:23 PM, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
As it stands, the new testing/btrfs-progs is building the same tools as the btrfs-progs-git PKGBUILD (albeit with !staticlibs), extra/btrfs-progs is still quite behind.
Once the testing package hits extra, btrfs-progs-git will be redundant (at least until Chris pulls in more commits). I guess the worth of btrfs-progs-git depends on how often Tom is planning on updating the commit ref in the official PKGBUILD and/or how often Chris pulls in changes to his tree. In general, official and official-git packages have different purposes.
btrfs-progs in official repos (testing/extra) should provides a released version. The btrfs-progs-git package is a _source_ package used to build a package with the _last_ git version (at the build time). At each release, the git package should ship the same content that the released one. Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On 17 September 2013 15:39, Sébastien Luttringer <seblu@seblu.net> wrote:
As it stands, the new testing/btrfs-progs is building the same tools as
On Tue, Sep 17, 2013 at 1:23 PM, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote: the
btrfs-progs-git PKGBUILD (albeit with !staticlibs), extra/btrfs-progs is still quite behind.
Once the testing package hits extra, btrfs-progs-git will be redundant (at least until Chris pulls in more commits). I guess the worth of btrfs-progs-git depends on how often Tom is planning on updating the commit ref in the official PKGBUILD and/or how often Chris pulls in changes to his tree. In general, official and official-git packages have different purposes.
btrfs-progs in official repos (testing/extra) should provides a released version. The btrfs-progs-git package is a _source_ package used to build a package with the _last_ git version (at the build time). At each release, the git package should ship the same content that the released one.
Cheers,
-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
Oops, I always forget that gmail defaults to top posting. Apologies for that. Also, I meant core/, not extra/.
In general, official and official-git packages have different purposes.
This is true, but until btrfs-progs starts releasing tagged versions again, it seems that btrfs-progs{,-git} will be providing the same thing (again, depending on how often the Mason tree gets updated and Tom updates the PKGBUILD). I'd like to reiterate that I'm in favour of having all three packages in the AUR, as I feel they all have value. btrfs-progs-git's usefulness will (hopefully) be restored/increased once btrfs-progs hits v0.20 proper. WorMzy
On 17 September 2013 16:06, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
On 17 September 2013 15:39, Sébastien Luttringer <seblu@seblu.net> wrote:
As it stands, the new testing/btrfs-progs is building the same tools as
On Tue, Sep 17, 2013 at 1:23 PM, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote: the
btrfs-progs-git PKGBUILD (albeit with !staticlibs), extra/btrfs-progs is still quite behind.
Once the testing package hits extra, btrfs-progs-git will be redundant (at least until Chris pulls in more commits). I guess the worth of btrfs-progs-git depends on how often Tom is planning on updating the commit ref in the official PKGBUILD and/or how often Chris pulls in changes to his tree. In general, official and official-git packages have different purposes.
btrfs-progs in official repos (testing/extra) should provides a released version. The btrfs-progs-git package is a _source_ package used to build a package with the _last_ git version (at the build time). At each release, the git package should ship the same content that the released one.
Cheers,
-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
Oops, I always forget that gmail defaults to top posting. Apologies for that. Also, I meant core/, not extra/.
In general, official and official-git packages have different purposes.
This is true, but until btrfs-progs starts releasing tagged versions again, it seems that btrfs-progs{,-git} will be providing the same thing (again, depending on how often the Mason tree gets updated and Tom updates the PKGBUILD).
I'd like to reiterate that I'm in favour of having all three packages in the AUR, as I feel they all have value. btrfs-progs-git's usefulness will (hopefully) be restored/increased once btrfs-progs hits v0.20 proper.
WorMzy
Okay, it looks like development on the -next branch has dried up and the latest dated snapshot is 16 commits ahead of it. Can someone remove btrfs-progs-unstable-git [1] please, it no longer makes sense. Sorry for the trouble. Cheers, WorMzy [1] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/
On Tue, Sep 24, 2013 at 9:54 PM, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
On 17 September 2013 16:06, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
On 17 September 2013 15:39, Sébastien Luttringer <seblu@seblu.net> wrote:
On Tue, Sep 17, 2013 at 1:23 PM, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
Okay, it looks like development on the -next branch has dried up and the latest dated snapshot is 16 commits ahead of it. Can someone remove btrfs-progs-unstable-git [1] please, it no longer makes sense. Sorry for the trouble.
Cheers,
WorMzy
[1] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/
btrfs-progs-unstable-integration-git removed. -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
participants (2)
-
Sébastien Luttringer
-
WorMzy Tykashi