> Fetch the desired duplicity source code from
> https://code.launchpad.net/duplicity/, unpack it and change
> in its directory. There, just issue
>
> + {{{
> - python setup.py install
> + python setup.py install}}}
I see the above fragment in the draft newsletter, and frankly
am disappointed at proposed content not using the packaging
system. It is clearly not a 'best practice'. The item in
question will run as root, and one assumes will over time be
updated and have security fixes.
In a CentOS publication, we should not be proposing installing
time bombs that a later admin 'cannot see'. We are all that
later admin as time packages and we forget the details of a
particular installation
-- Russ herrold
_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
04-21-2010, 01:58 PM
Timo Schoeler
u/d Newsletter/1003 by TimoSchoeler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
thus R P Herrold spake:
>> Fetch the desired duplicity source code from
>> https://code.launchpad.net/duplicity/, unpack it and change
>> in its directory. There, just issue
>>
>> + {{{
>> - python setup.py install
>> + python setup.py install}}}
>
> I see the above fragment in the draft newsletter, and frankly
> am disappointed at proposed content not using the packaging
> system. It is clearly not a 'best practice'. The item in
> question will run as root, and one assumes will over time be
> updated and have security fixes.
>
> In a CentOS publication, we should not be proposing installing
> time bombs that a later admin 'cannot see'. We are all that
> later admin as time packages and we forget the details of a
> particular installation
Hi,
I absolutely agree with you; my 'plan' was to write it that way (in the
draft), and -- if my spare time allows -- build an appropriate RPM and
maybe even get it integrated in one of the repos. Then, I could modify
it to the 'decent way'.
As backup plan, I could just continue and use the not up-to-date
rpmforge package.
> -- Russ herrold
Timo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
> thus R P Herrold spake:
>>> Fetch the desired duplicity source code from
>>> https://code.launchpad.net/duplicity/, unpack it and change
>>> in its directory. There, just issue
>>>
>>> + {{{
>>> - python setup.py install
>>> + python setup.py install}}}
>>
>> I see the above fragment in the draft newsletter, and frankly
>> am disappointed at proposed content not using the packaging
>> system. It is clearly not a 'best practice'. The item in
>> question will run as root, and one assumes will over time be
>> updated and have security fixes.
>>
>> In a CentOS publication, we should not be proposing installing
>> time bombs that a later admin 'cannot see'. We are all that
>> later admin as time packages and we forget the details of a
>> particular installation
>
> I absolutely agree with you; my 'plan' was to write it that way (in the
> draft), and -- if my spare time allows -- build an appropriate RPM and
> maybe even get it integrated in one of the repos. Then, I could modify
> it to the 'decent way'.
>
> As backup plan, I could just continue and use the not up-to-date
> rpmforge package.
Or provide a SPEC file for a duplicity update in RPMforge. It's not that
hard, but don't expect someone else to do it for you...
--
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
04-22-2010, 07:41 AM
Timo Schoeler
u/d Newsletter/1003 by TimoSchoeler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
thus Dag Wieers spake:
> On Wed, 21 Apr 2010, Timo Schoeler wrote:
>
>> thus R P Herrold spake:
>>>> Fetch the desired duplicity source code from
>>>> https://code.launchpad.net/duplicity/, unpack it and change
>>>> in its directory. There, just issue
>>>>
>>>> + {{{
>>>> - python setup.py install
>>>> + python setup.py install}}}
>>> I see the above fragment in the draft newsletter, and frankly
>>> am disappointed at proposed content not using the packaging
>>> system. It is clearly not a 'best practice'. The item in
>>> question will run as root, and one assumes will over time be
>>> updated and have security fixes.
>>>
>>> In a CentOS publication, we should not be proposing installing
>>> time bombs that a later admin 'cannot see'. We are all that
>>> later admin as time packages and we forget the details of a
>>> particular installation
>> I absolutely agree with you; my 'plan' was to write it that way (in the
>> draft), and -- if my spare time allows -- build an appropriate RPM and
>> maybe even get it integrated in one of the repos. Then, I could modify
>> it to the 'decent way'.
>>
>> As backup plan, I could just continue and use the not up-to-date
>> rpmforge package.
>
> Or provide a SPEC file for a duplicity update in RPMforge. It's not that
> hard,
I will try to do so ASAP, however my backlog is quite impressive ATM...
> but don't expect someone else to do it for you...
OK.
Cheers,
Timo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
u/d Newsletter/1003 by TimoSchoeler
