Re: bug#62401: [PATCH] home: Add home-syncthing-service-type.

[Ludovic Courtès]

Hi Bruno, Sergey, and all,

 is an attempt to provide a
consistent and simple way to “port” System services to Home, including
Syncthing, as discussed in this thread.

Let me know what you think!

Ludo’.

Re: The package/inherit trap

[Maxim Cournoyer]

Hello,

Mark H Weaver  writes:

> Simon Tournier  writes:
>
>> Hi Tobias,
>>
>> On Tue, 07 Mar 2023 at 22:11, Tobias Geerinckx-Rice  wrote:
>>
>>> However, merely documenting something is not enough when we have the
>>> chance to fix misleading naming, as we do here.  It would be nice to
>>> have, but orthogonal. 
>>
>> I would not say it is orthogonal because renaming would not have been
>> enough, at least for me, in order to get the difference with ’inherit’.
>>
>> For sure, it is a real trap. :-)  For instance,
>>
>> $ git log --grep='package/inherit' --oneline | grep use
>> 5f83dd03a2 gnu: kodi/wayland: Do not use package/inherit.
>> 6ecf88a6a1 gnu: poppler-next: Don't use 'package/inherit'.
>> 5a5b729d66 gnu: abseil-cpp: Don't use 'package/inherit'.
>> dbcf2b61b1 gnu: Fix erroneous uses of 'package/inherit'.
>> 2f97a666a5 gnu: python-urllib3: Don't use 'package/inherit' on 
>> replacement package.
>> 4163b6d855 gnu: avahi: Don't use package/inherit.
>>
>> and in the light of this discussion, 5f83dd03a2 seems incorrect, no?
>
> I agree that commit 5f83dd03a2 is incorrect.  'kodi/wayland' is quite
> clearly a case where 'package/inherit' should be used.

Would you be able to write a bit of doc explaining when both should be
used?  It's a common pitfalls among contributors, and I suspect few of
us have an understanding good enough to write it down in a manner clear
enough to be understood by new contributors.

-- 
Thanks,
Maxim

Re: The package/inherit trap

[Maxim Cournoyer]

Hi,

Attila Lendvai  writes:

>> How about 'package/variant' or 'package/variant-of'?
>
> +1 for trying to capture the intention in the name, instead of the means of 
> implementation.

I like 'package/variant'.  It should be possible to automatically update
our code base to use it, and deprecate the legacy name.

-- 
Thanks,
Maxim

Re: Reusing code for a build-phase?

[Csepp]

Hartmut Goebel  writes:

> Am 06.08.23 um 14:49 schrieb Csepp:
>> Maybe you could create a build system that inherits from the one these
>> packages use, but adds the extra phase.
>
> I was thinking about this, too. But this seems to be too much, as
> there are not hundreds of Vagrant plugins. Also a build-system
> requires documentation, wich is another pile of work.

There already are special purpose build systems, like the Minetest one.
I think you can just define it locally in the module and document it
with a comment, you don't necessarily have to make a module for it.
Alternatively you could write a function that modifies a package to add
the necessary phase.

I'm glad you brough this up, because I should test these ideas on my
MirageOS branch.  FWIW I think I'll go with the build system solution.