Re: [Caml-list] LablGtk3 beta1

["Emilio Jesús Gallego Arias" <e@x80.org>]

Hi David,

David Allsopp <dra-news@metastack.com> writes:

> My opinion is less humble - unnecessary duplication and having to
> maintain the same info in n places vs in 1 place is not a trade-off!
> :)

Sorry David I don't follow, but I don't see where the "n" copies gets
introduced in the approach I propose, could you provide an example?

> I don't think there's (yet) a formally written down policy - but there
> is the existence of those conf- packages (i.e. the chameleon principle
> - "do it like everyone else seems to be doing") and the comments of
> the maintainers expressing the desire for their use (and occasionally
> editing packages themselves to do it...)

I am not sure I can declare myself a fan of the "chameleon" principle :)
Indeed here I am talking as a "packager", so I guess I have different
tradeoffs.

> The solver needs to be aware of the universe of possible versions in
> order to be able to select (more below). It's not artificial - it just
> depends on how big you want your package universe to be and, rather
> more importantly, where you get the details of it from.

Both approaches add 1 package to the dependency tree, right?

> Your centralized database literally is the conf package - it already
> exists, there's no need for a change. You are proposing replacing the
> multiple entries in depext filtered by os-distribution with a single
> entry called gtk3.0 and having a central repository which has the
> os-distribution specific meanings of "gtk3.0" - it's the same thing.

I was talking under the assumption that we want to be able to express
the desired GTK version on the opam file itself. This is where the conf-
packages seem to not to work so well.

If we don't care about including versioned dependencies on GTK, as you
propose below, then indeed things are different.

> This confirms my original suspicion - the conf-gtk3 package should
> absolutely not be encoding the version test of GTK3, it should simply
> install it and just have an ultra-simple check that it works (like the
> other conf packages).

> but the conclusion should have been to stop trying to put the version
> test in conf-gtk3, not accuse conf- packages of being a broken
> concept.

> In order to depend on GTK you need a notion, in opam, of what "depend
> on GTK" means, and that notion is OS-, and even distribution-,
> specific - so it gets wrapped in the conf-gtk3 package. We can now say
> "in opam, to depend on GTK you depend on the conf-gtk3 package", and
> you no longer have to worry about OSes beyond your own (knowledge).

The origin of the discussion was indeed to inform OPAM about the GTK
version needed by lablgtk.

If we forget about versioning of system deps, then things are OK I
guess, but that seems like not the best user experience.

If I understand correctly then, as of today I could provide 2 lablgtk
opam packages, one depending on conf-gtk3, and one not depending on it,
and the user would actually have the same experience in the case of an
incorrect gtk version, right?

I can see the value on the conf-package today, but for subsystems that
are intrinsically versioned the approach doesn't seem to scale.

>> Having dependencies on depext would be a cool improvement, but that's not
>> necessary to have today IMHO in order to have a self-contained lablgtk
>> package.
>
> Again, I'm not very clear on what about the conf-gtk3 package makes
> you feel that lablgtk3 then becomes less "self-contained".

It is not clear to me who should maintain the conf packages. If I
imagine myself as a packager of lablgtk indeed I cannot then produce
working packages, worse, by depending on conf-gtk3 I cannot even
guarantee that my packages will be installable :(

E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs