On 06/22/2018 08:48 AM, clipka wrote:
> Am 22.06.2018 um 13:39 schrieb dick balaska:
> 
>> qtpovray_0.1
>> qtpovray-extras_0.1
>>
>> Should I call it 0.1?  3.8?  3.8.0.1?
>> 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
ja?

> 
>> 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 
my repo.
)

> 
>> I want to leverage the existing povray-includes
>> which requires a release of package povray-includes_3.8.0.0
>> 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_3.8.0.0 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.[78]
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.
/opt/povray/bin
/opt/povray/etc
/opt/povray/var/include

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_3.8.0.0 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.


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message