Question about 'provides' and emacs packaging

Question about 'provides' and emacs packaging

[Ken Brown]

I asked this question several years ago 
(https://cygwin.com/pipermail/cygwin-apps/2018-October/039451.html), but I'm 
repeating it, in a more specific form, in the hope that setup has progressed to 
the point where I get a different answer.

There are currently five emacs packages: emacs-common, emacs, emacs-X11, 
emacs-w32, and emacs-lucid.  The first includes things that are needed by each 
of the other four, and those four each include an emacs binary.  The binary in 
the emacs package is /usr/bin/emacs-nox.exe.  The other packages contain 
/usr/bin/emacs-X11.exe, and so on.

This way of naming the packages doesn't really reflect the contents of the emacs 
package.  It also means that anyone who installs emacs gets emacs-nox.exe, even 
if they plan to use one of the other three binaries.

I would rather rename the current emacs-common package to emacs and the current 
emacs package to emacs-nox.  But then the new emacs would have to have a way of 
requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, 
or emacs-lucid.  Is there any way to do this with our current setup machinery?

My idea three years ago was to have the new emacs package require a "feature" 
called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, 
emacs-w32, emacs-lucid "provide" that feature.  This is what Fedora does.  Achim 
didn't think this was feasible without major changes in setup.  Is that still 
the case?  If so, can anyone think of another way to accomplish what I want?

Thanks.

Ken

Re: Question about 'provides' and emacs packaging

[Brian Inglis]

On 2021-10-05 09:51, Ken Brown via Cygwin-apps wrote:
> I asked this question several years ago 
> (https://cygwin.com/pipermail/cygwin-apps/2018-October/039451.html), but 
> I'm repeating it, in a more specific form, in the hope that setup has 
> progressed to the point where I get a different answer.
> 
> There are currently five emacs packages: emacs-common, emacs, emacs-X11, 
> emacs-w32, and emacs-lucid.  The first includes things that are needed 
> by each of the other four, and those four each include an emacs binary.  
> The binary in the emacs package is /usr/bin/emacs-nox.exe.  The other 
> packages contain /usr/bin/emacs-X11.exe, and so on.
> 
> This way of naming the packages doesn't really reflect the contents of 
> the emacs package.  It also means that anyone who installs emacs gets 
> emacs-nox.exe, even if they plan to use one of the other three binaries.
> 
> I would rather rename the current emacs-common package to emacs and the 
> current emacs package to emacs-nox.  But then the new emacs would have 
> to have a way of requiring the installation of at least one of 
> emacs-nox, emacs-X11, emacs-w32, or emacs-lucid.  Is there any way to do 
> this with our current setup machinery?
> 
> My idea three years ago was to have the new emacs package require a 
> "feature" called, for instance, emacs-bin, and then have each of 
> emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature.  
> This is what Fedora does. Achim didn't think this was feasible without 
> major changes in setup. Is that still the case? If so, can anyone 
> think of another way to accomplish what I want?

Hi Ken,

Achim recently restructured gnuplot; I used to install gnuplot, 
gnuplot-base now obsoletes that, and that is all I have installed; 
alternatives handles the priorities if different packages provide gnuplot:

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gnuplot.git

gnuplot-base
depends2: cygwin, libcairo2, libcerf1, libgd3, libglib2.0_0, liblua5.3, 
libpango1.0_0, libreadline7

gnuplot-X11
depends2: cygwin, gnuplot-base, libX11_6, <BASE-DEPENDS2>...

gnuplot-qt5
depends2: cygwin, gnuplot-X11, libQt5Core5, libQt5Gui5, libQt5Svg5, 
libgcc1, <BASE-DEPENDS2>... libstdc++6

gnuplot-wx
depends2: cygwin, gnuplot-X11, libgcc1, <BASE-DEPENDS2>... libgtk3_0, 
libstdc++6, libwx_baseu3.0_0, libwx_gtk3u3.0_0

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Question about 'provides' and emacs packaging

[Ken Brown]

On 10/5/2021 12:58 PM, Brian Inglis wrote:
> On 2021-10-05 09:51, Ken Brown via Cygwin-apps wrote:
>> I asked this question several years ago 
>> (https://cygwin.com/pipermail/cygwin-apps/2018-October/039451.html), but I'm 
>> repeating it, in a more specific form, in the hope that setup has progressed 
>> to the point where I get a different answer.
>>
>> There are currently five emacs packages: emacs-common, emacs, emacs-X11, 
>> emacs-w32, and emacs-lucid.  The first includes things that are needed by each 
>> of the other four, and those four each include an emacs binary. The binary in 
>> the emacs package is /usr/bin/emacs-nox.exe.  The other packages contain 
>> /usr/bin/emacs-X11.exe, and so on.
>>
>> This way of naming the packages doesn't really reflect the contents of the 
>> emacs package.  It also means that anyone who installs emacs gets 
>> emacs-nox.exe, even if they plan to use one of the other three binaries.
>>
>> I would rather rename the current emacs-common package to emacs and the 
>> current emacs package to emacs-nox.  But then the new emacs would have to have 
>> a way of requiring the installation of at least one of emacs-nox, emacs-X11, 
>> emacs-w32, or emacs-lucid.  Is there any way to do this with our current setup 
>> machinery?
>>
>> My idea three years ago was to have the new emacs package require a "feature" 
>> called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, 
>> emacs-w32, emacs-lucid "provide" that feature. This is what Fedora does. Achim 
>> didn't think this was feasible without major changes in setup. Is that still 
>> the case? If so, can anyone think of another way to accomplish what I want?
> 
> Hi Ken,
> 
> Achim recently restructured gnuplot; I used to install gnuplot, gnuplot-base now 
> obsoletes that, and that is all I have installed; alternatives handles the 
> priorities if different packages provide gnuplot:
> 
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gnuplot.git
> 
> gnuplot-base
> depends2: cygwin, libcairo2, libcerf1, libgd3, libglib2.0_0, liblua5.3, 
> libpango1.0_0, libreadline7
> 
> gnuplot-X11
> depends2: cygwin, gnuplot-base, libX11_6, <BASE-DEPENDS2>...
> 
> gnuplot-qt5
> depends2: cygwin, gnuplot-X11, libQt5Core5, libQt5Gui5, libQt5Svg5, libgcc1, 
> <BASE-DEPENDS2>... libstdc++6
> 
> gnuplot-wx
> depends2: cygwin, gnuplot-X11, libgcc1, <BASE-DEPENDS2>... libgtk3_0, 
> libstdc++6, libwx_baseu3.0_0, libwx_gtk3u3.0_0

This is very similar to what I currently have in emacs, although with better 
names.  gnuplot-base is comparable to emacs-common+emacs.  It doesn't achieve 
what I was asking for.  But if what I was asking for isn't possible, I might 
still do some renaming, to make the contents clearer.

Thanks.

Ken

Re: Question about 'provides' and emacs packaging

[Achim Gratz]

Ken Brown via Cygwin-apps writes:
> There are currently five emacs packages: emacs-common, emacs,
> emacs-X11, emacs-w32, and emacs-lucid.  The first includes things that
> are needed by each of the other four, and those four each include an
> emacs binary.  The binary in the emacs package is
> /usr/bin/emacs-nox.exe.  The other packages contain
> /usr/bin/emacs-X11.exe, and so on.
>
> This way of naming the packages doesn't really reflect the contents of
> the emacs package.  It also means that anyone who installs emacs gets
> emacs-nox.exe, even if they plan to use one of the other three
> binaries.
>
> I would rather rename the current emacs-common package to emacs and
> the current emacs package to emacs-nox.  But then the new emacs would
> have to have a way of requiring the installation of at least one of
> emacs-nox, emacs-X11, emacs-w32, or emacs-lucid.  Is there any way to
> do this with our current setup machinery?

I don't think we have the transaction capability that would be necessary
to specify that the meaning of an already existing package name (two,
actually) changes in this manner.  You might have to use new package
names and place the appropriate obsoletions w.r.t. old names instead.

> My idea three years ago was to have the new emacs package require a
> "feature" called, for instance, emacs-bin, and then have each of
> emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature.

I have no idea if multiple packages can provide the same feature. It's
worth trying if it does what you want (you must pick at least one of
those).  What I'm reasonably sure we currently don't have is packages
providing the same feature, but conflicting among each other (you must
install one and only one package that provides the feature).  What calm
thinks of that is another thing entirely, I'd say.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Question about 'provides' and emacs packaging

[Ken Brown]

On 10/5/2021 2:24 PM, Achim Gratz wrote:
> Ken Brown via Cygwin-apps writes:
>> There are currently five emacs packages: emacs-common, emacs,
>> emacs-X11, emacs-w32, and emacs-lucid.  The first includes things that
>> are needed by each of the other four, and those four each include an
>> emacs binary.  The binary in the emacs package is
>> /usr/bin/emacs-nox.exe.  The other packages contain
>> /usr/bin/emacs-X11.exe, and so on.
>>
>> This way of naming the packages doesn't really reflect the contents of
>> the emacs package.  It also means that anyone who installs emacs gets
>> emacs-nox.exe, even if they plan to use one of the other three
>> binaries.
>>
>> I would rather rename the current emacs-common package to emacs and
>> the current emacs package to emacs-nox.  But then the new emacs would
>> have to have a way of requiring the installation of at least one of
>> emacs-nox, emacs-X11, emacs-w32, or emacs-lucid.  Is there any way to
>> do this with our current setup machinery?
> 
> I don't think we have the transaction capability that would be necessary
> to specify that the meaning of an already existing package name (two,
> actually) changes in this manner.  You might have to use new package
> names and place the appropriate obsoletions w.r.t. old names instead.
> 
>> My idea three years ago was to have the new emacs package require a
>> "feature" called, for instance, emacs-bin, and then have each of
>> emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature.
> 
> I have no idea if multiple packages can provide the same feature. It's
> worth trying if it does what you want (you must pick at least one of
> those).

This seems to work, with one caveat.  Suppose package P requires feature f, and 
packages Q, R, S,... provide f.  If the user selects P and one or more of Q, R, 
S,..., setup is happy.  But if the user simply selects P, then setup/libsolv 
will choose among Q, R, S,... the one whose name is alphabetically first.  In 
the emacs case, this would be emacs-lucid, which is a stupid default.  The 
default ought to be emacs-nox.  So I can make it work if I call that package 
emacs-basic instead of emacs-nox.

I've only tested setup so far, not calm.  Jon, if you're reading this, does calm 
allow 'requires' and 'provides' to contain arbitrary names that are not package 
names?

Ken

Re: Question about 'provides' and emacs packaging

[ASSI]

Ken Brown via Cygwin-apps writes:
> I've only tested setup so far, not calm.  Jon, if you're reading this,
> does calm allow 'requires' and 'provides' to contain arbitrary names
> that are not package names?

Yes, Perl is using that to ensure that the distribution packages get
updated according to the Perl version,


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Question about 'provides' and emacs packaging

[Jon Turney]

On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote:
> On 10/5/2021 2:24 PM, Achim Gratz wrote:
>> Ken Brown via Cygwin-apps writes:
>>> There are currently five emacs packages: emacs-common, emacs,
>>> emacs-X11, emacs-w32, and emacs-lucid.  The first includes things that
>>> are needed by each of the other four, and those four each include an
>>> emacs binary.  The binary in the emacs package is
>>> /usr/bin/emacs-nox.exe.  The other packages contain
>>> /usr/bin/emacs-X11.exe, and so on.
>>>
>>> This way of naming the packages doesn't really reflect the contents of
>>> the emacs package.  It also means that anyone who installs emacs gets
>>> emacs-nox.exe, even if they plan to use one of the other three
>>> binaries.
>>>
>>> I would rather rename the current emacs-common package to emacs and
>>> the current emacs package to emacs-nox.  But then the new emacs would
>>> have to have a way of requiring the installation of at least one of
>>> emacs-nox, emacs-X11, emacs-w32, or emacs-lucid.  Is there any way to
>>> do this with our current setup machinery?
>>
>> I don't think we have the transaction capability that would be necessary
>> to specify that the meaning of an already existing package name (two,
>> actually) changes in this manner.  You might have to use new package
>> names and place the appropriate obsoletions w.r.t. old names instead.
>>
>>> My idea three years ago was to have the new emacs package require a
>>> "feature" called, for instance, emacs-bin, and then have each of
>>> emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature.
>>
>> I have no idea if multiple packages can provide the same feature. It's
>> worth trying if it does what you want (you must pick at least one of
>> those).
> 
> This seems to work, with one caveat.  Suppose package P requires feature 
> f, and packages Q, R, S,... provide f.  If the user selects P and one or 
> more of Q, R, S,..., setup is happy.  But if the user simply selects P, 
> then setup/libsolv will choose among Q, R, S,... the one whose name is 
> alphabetically first.  In the emacs case, this would be emacs-lucid, 
> which is a stupid default.  The default ought to be emacs-nox.  So I can 
> make it work if I call that package emacs-basic instead of emacs-nox.

Yeah, I think what's wanted here is for the solver to output a problem 
with the choices, rather than picking one.  I'm not sure how to get it 
to do that.

(Ofc, then we need some UI for picking problem solutions, rather than 
just always using the default)

(and I'm not sure how we'd encode "emacs-basic" should be the default 
provider of "emacs-bin" as the input into the solver; presumably there'd 
by some scheme with weights attached to provide names to set the order 
rather than alphabetic)

> I've only tested setup so far, not calm.  Jon, if you're reading this, 
> does calm allow 'requires' and 'provides' to contain arbitrary names 
> that are not package names?

Yes.

Re: Question about 'provides' and emacs packaging

[Jon Turney]

On 06/10/2021 17:23, Jon Turney wrote:
> On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote:
>>
>> This seems to work, with one caveat.  Suppose package P requires 
>> feature f, and packages Q, R, S,... provide f.  If the user selects P 
>> and one or more of Q, R, S,..., setup is happy.  But if the user 
>> simply selects P, then setup/libsolv will choose among Q, R, S,... the 
>> one whose name is alphabetically first.  In the emacs case, this would 
>> be emacs-lucid, which is a stupid default.  The default ought to be 
>> emacs-nox.  So I can make it work if I call that package emacs-basic 
>> instead of emacs-nox.
> 
> Yeah, I think what's wanted here is for the solver to output a problem 
> with the choices, rather than picking one.  I'm not sure how to get it 
> to do that.
> 
> (Ofc, then we need some UI for picking problem solutions, rather than 
> just always using the default)

Thinking about this some more, that's probably not how it wants to work, 
since just installing emacs-common would then require user interaction 
to solve the problem, rather than just installing emacs-nox as well...

> (and I'm not sure how we'd encode "emacs-basic" should be the default 
> provider of "emacs-bin" as the input into the solver; presumably there'd 
> by some scheme with weights attached to provide names to set the order 
> rather than alphabetic)

So all that's left is to fix that.

This is discussed somewhat in [1], and it seems that having emacs-common 
suggest: or weak-dep: on emacs-nox would cause that to be the preferred 
provide:r by the solver (in the absence of other provide:ing packages 
being selected or installed)

So I guess we'd need to add something like that to setup.ini and feed 
that data into the solver as well.

[1] https://github.com/openSUSE/libsolv/issues/66

Re: Question about 'provides' and emacs packaging

[Ken Brown]

On 10/6/2021 4:22 PM, Jon Turney wrote:
> On 06/10/2021 17:23, Jon Turney wrote:
>> On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote:
>>>
>>> This seems to work, with one caveat.  Suppose package P requires feature f, 
>>> and packages Q, R, S,... provide f.  If the user selects P and one or more of 
>>> Q, R, S,..., setup is happy.  But if the user simply selects P, then 
>>> setup/libsolv will choose among Q, R, S,... the one whose name is 
>>> alphabetically first.  In the emacs case, this would be emacs-lucid, which is 
>>> a stupid default.  The default ought to be emacs-nox.  So I can make it work 
>>> if I call that package emacs-basic instead of emacs-nox.
>>
>> Yeah, I think what's wanted here is for the solver to output a problem with 
>> the choices, rather than picking one.  I'm not sure how to get it to do that.
>>
>> (Ofc, then we need some UI for picking problem solutions, rather than just 
>> always using the default)
> 
> Thinking about this some more, that's probably not how it wants to work, since 
> just installing emacs-common would then require user interaction to solve the 
> problem, rather than just installing emacs-nox as well...

Agreed.

>> (and I'm not sure how we'd encode "emacs-basic" should be the default provider 
>> of "emacs-bin" as the input into the solver; presumably there'd by some scheme 
>> with weights attached to provide names to set the order rather than alphabetic)
> 
> So all that's left is to fix that.
> 
> This is discussed somewhat in [1], and it seems that having emacs-common 
> suggest: or weak-dep: on emacs-nox would cause that to be the preferred 
> provide:r by the solver (in the absence of other provide:ing packages being 
> selected or installed)

Yes, that sounds right...

> So I guess we'd need to add something like that to setup.ini and feed that data 
> into the solver as well.

...but I'm not sure it's worth the trouble unless other package maintainers 
would also have a use for this.  As far as emacs is concerned, I'm fine just 
changing "emacs-nox" to "emacs-basic" so that it's alphabetically first.

Ken