[Hamara-devel] Approach for Packaging in Hamara 2.0 "Svastik"

[Dhanesh Sabane]

On 08/25/2018 08:20 PM, Pirate Praveen wrote:
> On ശനി 25 ഓഗസ്റ്റ് 2018 07:23 വൈകു, Vikas Tara wrote:
>> Hi,
>>
>> This is something that needs to be finalised still.
>>
>> We are proposing basing on debian testing so that there are newer
>> packages than stable.
> 
> Another option is going stable + backports, in that case a subset of
> newer packages in unstable will be available based on popularity.
> 

I may be wrong but the motivation to move Hamara's base to Debian 
testing was to make sure that the latest software is made available to 
the end user. To maintain that motivation and also have stable + 
backports will end up in a huge subset of packages from unstable which 
isn't ideal, IMO.

>> However there are quite a few things which are not yet packaged in
>> debian testing but will be as it comes closer to stable.
>>
>> Unstable often does have the packages, but unstable is not recommended
>> for everyday use.
> 
> When a package is in unstable but not in testing, usually it means there
> is a release critical bug or it can break other packages in testing.
> 
>> We have also talked about having our own testing repo in between
>> upstream and our live repo. We would be able to maintain a test version
>> of svastik that way.
> 

I'm completely in support of having a testing repo in between. It will 
give us the flexibility to experiment with the distro while keeping the 
end deliverable stable.

> Even in that case, either you have to compromise on bugs or will have to
> choose a subset. For example take ruby-sanitize (a package that I worked
> on recently). It had version 2 in testing which has a security bug,
> unstable had version 4 for some time, but there were other packages in
> testing which were not ready yet for sanitize 4. I had to make sure all
> packages are made compatible with sanitize version 4 before I got it
> into testing. I don't think your own repo will solve this case unless
> you have to choose only a subset of packages in that case the effort to
> ensure compatibility will also reduce.
> 

I believe it will only be about a small subset of packages that we'll 
have to take some effort for.

>> We have some options here to help fill the gaps:
>>
>> 1. work with (and encourage more people to become) debian developers to
>> help move things from unstable to testing to help meet our own release
>> cycle (good for everyone)
> 
> +1

A huge +1 for this.

>> 2. where that is not possible, use flatpak/snap approach to package
>> things from either stable or unstable
> 
> Be warned that, it means duplication, because you will have keep
> maintaining multiple versions of libraries (one for apt and another for
> flatpack).
> 

I don't think we should officially support flatpak/snap packages. Let 
the users experiment with that. We can provide guides, if necessary.

>> 3. ideas where 1 and 2 are not possible?
>>
>> Any other comments / ideas?
> 
> I think it would be good to join forces with PurOS and LMDE to share the
> work load. I think LMDE has a stabilizing repo between LMDE and debian
> testing.
> 

I like the idea. All of us could really benefit from the combined work 
force. I think we should attract a few more contributors and go ahead 
with this approach.

-- 
Dhanesh B. Sabane
https://dhanesh95.gitlab.io
PGP ID: 0xB69A98C9C1642329
Fingerprint: 9655 11F2 0D18 E76A 2396  D64D B69A 98C9 C164 2329