On 06/22/2018 08:48 AM, clipka wrote:
> Am 22.06.2018 um 13:39 schrieb dick balaska:
>> Should I call it 0.1? 3.8? 184.108.40.206?
>> qtpovray contains the executable and desktop
>> qtpovray-extras contains the glorious insert menu
> I'd make sure that it is clear which version of POV-Ray it is based on.
> For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
> POV-Ray vX.Y.Z.
I can do that. So my first would be qtpovray-3.80.1
>> Maybe I should call qtpovray-extras just povray-extras?
> No, you should definitely not. If it's not official POV-Ray, don't make
> it look like it is.
Well, that was my first thought. But, OTOH, there is no "official"
povray, so screw all y'all. ;)
All praise to Andreas Beckmann <anb### [at] debianorg> (who I never heard of)
as the debian maintainer.
I have read so much debian foo lately. It's too much. Then I unpacked
the debian povray port, and it's all right there, with all the right
magic words to make 3 packages from one set of source. The only hard
part was was bootstrapping qmake, for which the only documentation is a
comment in a tutorial. "How do I use qmake instead of configure?" "Since
version blah, it just magically works".
jr whined that I didn't rename my dir root from povray to qtpovray. The
fact that I didn't bit me in the butt here. Package qtpovray must be
built from dir root qtpovray. Then it sees qtpovray.pro first and
ignores any ./configure that lives there. I'm going to have to rename
>> I want to leverage the existing povray-includes
>> which requires a release of package povray-includes_220.127.116.11
>> to pick up /usr/share/povray-3.8/includes .
>> Also, to get the .ini files especially /etc/povray/3.8/povray.conf
>> I need package povray_18.104.22.168 and we're not ready for that.
> In my naive understanding of Unix package management, I would suggest
> for now to release qtpovray as a collection of stand-alone packages, and
> later - once an official POV-Ray package is available - update it to
> make use of the official POV-Ray packages, modifying part of the
> qtpovray packages to do nothing more than pull in the official packages.
I will do that.
Although I would prefer if the data was in /usr/share/povray/3.
I will be consistent and go with /usr/share/qtpovray-3.81 to match the
existing style of /usr/share/povray-3.7
(Actually my personal preference is to keep it *all* together, i.e.
I'm not a real fan of the debian model of sowing povray dust throughout
the file system. But it works for a couple hundred million (a billion?)
installations, so it's good enough for me.
>> I could release a qmake built package povray_22.214.171.124 with the unix shell
>> version (and the /etc/povray/3.8 files I need). But that's not my call
>> (or true focus). One bleh thing about that is the executable is
>> /usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at
>> the same time, even though the data is already separated by version.
> I'd say that's a thing to be addressed by whoever is the maintainer of
> the debian POV-Ray package. We're not doing any Unix package
> maintenance, we're just providing the source code, Unix build tools, and
> a bit of support. If I'm not mistaken, the configure script allows to
> specify a different binary name >
> If they're smart, the package also has a `/usr/bin/povray-3.7`
> hard-linked to the same file (or `/usr/bin/povray` soft-linked to
> `/usr/bin/povray-3.7`), so that installing another version "on top" of
> it leaves an instance of the old binary available.
99% of packages don't do symlinks. But the big boys do; gcc, python,
wish. I will suggest this to the debian maintainer.
Rendered 328976 of 330000 (99%)
Post a reply to this message