[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master



On 03/02/18 13:07, Fabian Grünbichler wrote:
> 
> (CC-ing the existing ZoL Debian packaging team, although there is hardly
> ever any response there..)
> 
> as an upstream contributor and with my downstream/derivative hat on I
> have an alternative proposal:
> 
> I've been pondering cleaning up and pushing the existing Debian
> packaging (or some variant thereof) upstream to replace the ugly "build
> rpms and use alien + various hacks to get some sort of .deb output"
> "build system" that is currently used.
> 
> it seems like upstream is just lacking the people and knowledge to do
> this, but it would be welcome (see config/deb.am). would you be
> interested in teaming up on this?
I think that this is a great idea, and I would definitely like to
collaborate on this. I'll start a discussion with you off-list about
this. Maybe a feature request on upstream's bug tracker.

> 
> there are quite a lot of people running git master or the latest 0.7.x
> release on some variant of Debian/Ubuntu that get tripped up on every
> other release because of missing files and lack of integration into
> Debian tooling, probably more than would be willing/able to track
> experimental ;)
> 
> this would also have the big upside of being able to integrate the
> upstream Debian packaging directly into zfs-buildbot infrastructure,
> hopefully keeping most of the packaging-related issues we've seen in the
> past from being part of any tagged releases in the future.
I was already sold. An automatically up-to-date upstream apt repository
would be a great boon for zfsonlinux adoption, and possible, like you're
saying.

> 
> the only real downside I see is the fact the the debian/ folder would
> need to be excluded when importing stable upstream releases into Debian
> proper, in favor of cherry-picking the relevant packaging changes only
> as separate commits afterwards (but this is easy with the existing GBP
> workflow, and something that a lot of packages with upstream debian/
> folders handle just fine).

I still think that getting an experimental package into Debian would
improve access to Debian users. Moreover, another (perhaps the most)
import objective of my proposal is to *reduce* workload on the existing
zfsonlinux team. I'll support any proposal that makes their life easier,
and my though is that a continuously up-to-date Debian experimental
package that can be directly imported on, e.g., release-day should help
out.


Reply to: