Re: Packaging mmh (fork of nmh)

[Dmitry Bogatov]

> >So, it is okay to use alternatives to manage /usr/bin/mh symlink (I 
> >will need your cooperation, Jakub)
> I think you're confusing me with someone else...

Sorry again. With your statement about nmh content I thought, that
you are nmh maintainer.

> >, but what about manpages?
> >
> >Creating alternative for every manpage is too complicated.
>
> It's just a bunch of extra slave links. I doesn't look complicated to
> me.

It would be confusing, that `man scan' can refer to mmh, but `man mhshow'
to nmh, since such command is absent in `mmh'.

> >Is possible to somehow create subdirectory /usr/share/man/man1/mh and
> >have it availiable to man?
>
> I don't think so.

What about custom hooks, triggered on every alternative change?

> What you could do is to put the manpages into a different section[0], so
> that mmh's manpage files don't conflict with nmh's ones. But then it
> wouldn't be guaranteed that, say, "man mhl" will give the manpage
> corresponding to /usr/bin/mh/mhl.

It is terrible confusing. Only if I alternatives could affect section
resolution order...

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Packaging mmh (fork of nmh)

[Jakub Wilk]

* Dmitry Bogatov , 2016-04-11, 10:06:
So, it is okay to use alternatives to manage /usr/bin/mh symlink (I 
will need your cooperation, Jakub)


I think you're confusing me with someone else...


, but what about manpages?

Creating alternative for every manpage is too complicated.


It's just a bunch of extra slave links. I doesn't look complicated to 
me.


Is possible to somehow create subdirectory /usr/share/man/man1/mh and 
have it availiable to man?


I don't think so.

What you could do is to put the manpages into a different section[0], so 
that mmh's manpage files don't conflict with nmh's ones. But then it 
wouldn't be guaranteed that, say, "man mhl" will give the manpage 
corresponding to /usr/bin/mh/mhl".



[0] nmh manpages use the "mh" suffix after the section number; so you 
could use the "mmh" suffix.


--
Jakub Wilk

Re: Packaging mmh (fork of nmh)

[Dmitry Bogatov]

[2016-04-10 17:15] Jakub Wilk 
>
> * Wookey , 2016-04-10, 15:49:
> >>nmh installs it's binaries (~20) into /usr/bin/nmh.
>
> Actually it installs to /usr/bin/mh, ...

Sorry, my memory served me bad.

> >Are nmh and mmh intended to be co-installable? I presume that you want
> >one or the other, so making them conflict like MTAs would make sense.
>
> Conveniently, nmh already has Conflicts+Replaces+Provides for virtual
> package "mh". It would make sense to add the same C+R+P to mmh.

Ideally, they should be *co-installable*. This is wish (just a wish)
of mmh upstream and probably the right thing to do. I had to state it
more explicitly.

So, it is okay to use alternatives to manage /usr/bin/mh symlink (I
will need your cooperation, Jakub), but what about manpages?

Creating alternative for every manpage is too complicated. Is possible
to somehow create subdirectory /usr/share/man/man1/mh and have it
availiable to man? Seems, it will require rehashing of manpages database
every alternatives switch, though.

In general, any ideas how make them co-installable without too much pain
and FHS violation?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Re: Packaging mmh (fork of nmh)

[Wookey]

+++ Jakub Wilk [2016-04-10 17:15 +0200]:
> * Wookey , 2016-04-10, 15:49:
> >>nmh installs it's binaries (~20) into /usr/bin/nmh.
> 
> Actually it installs to /usr/bin/mh, ...
> 
> >>Now I try to do the same, and install mmh's binaries into /usr/bin/mmh,
> >>but Lintian complain about FHS violation. The only allowed subdir of
> >>/usr/bin is /usr/bin/mh.
> >
> >So nmh is not following FHS either.
> 
> ...which is permitted by FHS.

Right. I took what the OP said at face value, rather than checking up :-)
 
> >>Installing mmh into /usr/bin/mh would be impolite to `nmh', since `mh'
> >>is historical name, like `vi'.

So mmh should probably just use /usr/bin/mh as well? (and C+R+P). Any
reason why that wouldn't work?

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Packaging mmh (fork of nmh)

[Russ Allbery]

Wookey  writes:
> +++ Dmitry Bogatov [2016-04-10 08:34 +0300]:

>> nmh installs it's binaries (~20) into /usr/bin/nmh. Now I try to
>> do the same, and install mmh's binaries into /usr/bin/mmh, but
>> Lintian complain about FHS violation. The only allowed
>> subdir of /usr/bin is /usr/bin/mh.

> So nmh is not following FHS either. 

mh implementations have a special historical exception in the FHS.

-- 
Russ Allbery (r...@debian.org)   

Re: Packaging mmh (fork of nmh)

[Jakub Wilk]

* Wookey , 2016-04-10, 15:49:

nmh installs it's binaries (~20) into /usr/bin/nmh.


Actually it installs to /usr/bin/mh, ...

Now I try to do the same, and install mmh's binaries into 
/usr/bin/mmh, but Lintian complain about FHS violation. The only 
allowed subdir of /usr/bin is /usr/bin/mh.


So nmh is not following FHS either.


...which is permitted by FHS.

Installing mmh into /usr/bin/mh would be impolite to `nmh', since `mh' 
is historical name, like `vi'.


Are nmh and mmh intended to be co-installable? I presume that you want 
one or the other, so making them conflict like MTAs would make sense.


Conveniently, nmh already has Conflicts+Replaces+Provides for virtual 
package "mh". It would make sense to add the same C+R+P to mmh.


--
Jakub Wilk

Re: Packaging mmh (fork of nmh)

[Wookey]

+++ Dmitry Bogatov [2016-04-10 08:34 +0300]:
> 
> [CC nmh maintainer]
> 
> Hello!
> 
> I am packaging mmh (http://marmaro.de/prog/mmh), which is fork of
> nmh. Both of them are mail user agents.
> 
> nmh installs it's binaries (~20) into /usr/bin/nmh. Now I try to
> do the same, and install mmh's binaries into /usr/bin/mmh, but
> Lintian complain about FHS violation. The only allowed
> subdir of /usr/bin is /usr/bin/mh.

So nmh is not following FHS either. 
 
> Installing mmh into /usr/bin/mh would be impolite to `nmh', since
> `mh' is historical name, like `vi'.

Are nmh and mmh intended to be co-installable? I presume that you want
one or the other, so making them conflict like MTAs would make sense.

> So I consider using alternatives mechanism. Unfortunately,
> `mmh' and `nmh' are not totally equivalent -- mmh has lesser
> count of commands. I think about alternatives not for binaries,
> but for whole directories:
> 
> /usr/bin/mh -> /usr/lib/nmh | /usr/lib/mmh
> /etc/mh -> /etc/nmh | /etc/mmh
> ...
> 
> Is it allowed? Is it good solution? 

It seems sensible to me.

> And what to do with man pages?
> For example, both provides `scan(1)', but only `nmh' has `mhshow(1)'.

Well, if you only install one or the other this isn't a problem - they both 
just provide
a suitable set of manpages.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Packaging mmh (fork of nmh)

[Dmitry Bogatov]

[CC nmh maintainer]

Hello!

I am packaging mmh (http://marmaro.de/prog/mmh), which is fork of
nmh. Both of them are mail user agents.

nmh installs it's binaries (~20) into /usr/bin/nmh. Now I try to
do the same, and install mmh's binaries into /usr/bin/mmh, but
Lintian complain about FHS violation. The only allowed
subdir of /usr/bin is /usr/bin/mh.

Installing mmh into /usr/bin/mh would be impolite to `nmh', since
`mh' is historical name, like `vi'.

So I consider using alternatives mechanism. Unfortunately,
`mmh' and `nmh' are not totally equivalent -- mmh has lesser
count of commands. I think about alternatives not for binaries,
but for whole directories:

/usr/bin/mh -> /usr/lib/nmh | /usr/lib/mmh
/etc/mh -> /etc/nmh | /etc/mmh
...

Is it allowed? Is it good solution? And what to do with man pages?
For example, both provides `scan(1)', but only `nmh' has `mhshow(1)'.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io