[Debian-olpc-devel] 'rainbow' uploaded to mentors.debian.net

Mon Nov 16 17:00:56 UTC 2009

On Mon, Aug 31, 2009 at 04:29:52PM -0400, Luke Faraone wrote:
>On Sun, Aug 30, 2009 at 09:08, Jonas Smedegaard <dr at jones.dk> wrote:
>
>> Why do you patch to install into /usr/sbin rather than /usr/bin?  
>> Aren't those binaries supposed to be executed by ordinary users?
>>
>
>rainbow-run and rainbow-easy can only be run as root, thus they are 
>(IMHO) *s*ystem *bin*aries. rainbow-xify, mkenvdir, and 
>rainbow-sugarize probably belong in /usr/bin though...  I'll fix that 
>shortly.

Ok.  Makes sense.

>> I notice that you include ${cdbs:Recommends} and similar in 
>> debian/control, but still include explicit dependencies as well.  The 
>> intend of those variables is to move all package dependency handling 
>> to debian/rules.  See debian/rules of e.g. sugar for an example.
>>
>
>Okay, I removed the ${cdbs:Recommends}.

ok.

Personally I prefer to maintain the dependencies in debian/rules (as it 
allows for verbose comments on *why* each dependency is as it is).  But 
following the more common style of not documenting dependencies is 
certainly ok too.

>> Where is the "upstream" branch holding the virgin upstrema code?  Did 
>> you not use git-import-orig to bootstrap the packaging?  
>> "pristine-tar" branch is missing too.  Please use both --pristine-tar 
>> and --sign-tags options to inject upstream tarballs.
>
>
>No idea. I used "git-import-dsc" per the 
>http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ , which 
>seemed an authoritative guide.

git-buildpackage are semi-generic tools, allowing multiple packaging 
styles.

My questions do not imply that you are doing something wrong, just that 
I am wondering *if* your actions were deliberate or maybe accidental.

Personally, I favor the packaging style described below.

>> Here's how I usually start a new packaging:
>>
>> wget http/example.org/pkgname-1.2.tgz
>> mv pkgname-1.2.tgz pkgname_1.2.orig.tar.gz
>> mkdir pkgname
>> cd pkgname
>> git init
>> git-import-orig --sign-tags --pristine-tar ../pkgname_1.2.orig.tar.gz
>>
>> You can either start from scratch again (and please do apply each 
>> change as a separate commit to help tracking what is what), or I can 
>> try merge a virgin proper bootstrap with your branch.  Tell me how 
>> you want us to deal with it.
>>
>
>Can you do it? I tried and can't seem to do so "properly".

I can, but would prefer to help you learn it too: I expect you to do 
*lots* of packages in the future, and it would be a pity if you would 
continue to depend on me bootstrapping each of them :-D

So please elaborate in more details: What did you try, and what failed?

>> Why do you include the version number of the NSS module?  I suspect 
>> only shared libraries should include a trailing major version, and 
>> that NSS modules are not normal shared libraries.  Again, compare 
>> with other NSS modules for how they do things (without duplicating 
>> blindly - e.g. we use CDBS while some of them might use incompatible 
>> debhelper 7 "dh").
>>
>
>At least two NSS modules include trailing version numbers. Lintian was 
>tossing a warning unless I did so. If you'd rather, I can drop it and 
>silence Lintian.

What was the lintian warning?  I would like to understand the issue 
better.

>Why do you install /var - that looks odd to me.
>>
>
>That directory is required by Rainbow, as that is where isolated 
>instances will be located. Rainbow will not work without this 
>directory. Should I create it in the postinst?

/var is part of LSB (Linux Standard Base) as the FHS (File Hierarchy 
Standard) - or maybe just one of those acronyms.  I believe you need not 
(and should not) declare parts of the system that is required to always 
be available.

Also, it seems odd to me if Rainbow do not use some private location 
_below_ /var for its special structures.

>> Are you sure you should install /usr/lib/python*? - I suspect that is 
>> taken care of by the python-distutils.mk snippet, and installing 
>> directly actually violates Python policy!
>>
>
>If you look at the build .debs, there shouldn't be anything in 
>/usr/lib/python, but that snippit was required for me to get the right 
>code in the right place.

Oh, I understand it now.

>> Why do you set DEB_MAKE_MAKEFILE?
>
>
>Hm? I don't see that anywhere in my debian/rules file.

Sorry - I meant DEB_MAKE_INSTALL_TARGET.

And I think I see it now:

But that upstream mixture of make and python-distutils is problematic: 
the makefile handles Python code too simplistic for Debian needs (e.g. 
simply invokes unversioned python rather than taking into account the 
packaging hints on which version to use)!

You should recommend upstream to use autotools with Python integration, 
as done in the core sugar packages.

As workaround until possibly improved upstream, I suggest to avoid using 
the makefile directly and instead replicate the non-python parts of it 
in debian/rules.  In other words, drop the makefile.mk cdbs snippet, and 
instead include makefile-vars.mk, and attach e.g. $(DEB_MAKE_INVOKE) to 
the relevant core cdbs rules (tell me if you need help figuring those 
out) directly in debian/rules.

>> Why set DEB_PYTHON_MODULE_PACKAGES - I believe that should be 
>> autodetected if using proper package names.  Even if not, I still 
>> suspect that you should rename the package to include a leading 
>> "python-" to not violate Python Policy.
>>
>
>How about this: I'll split it off into three packages: rainbow, 
>python-rainbow, and libnss-rainbow2.

That's really two (related) issues here:

  * declaring DEB_PYTHON_MODULE_PACKAGES
  * naming binary packages according to Python policy

The cdbs python-distutils.mk snippet by defeault sets 
DEB_PYTHON_MODULE_PACKAGES to match Python Policy - so if following 
policy you should not need to mess with overriding 
DEB_PYTHON_MODULE_PACKAGES at all.

If, for some odd reason, you need to set DEB_PYTHON_MODULE_PACKAGES, 
then you must do it _before_ loading the cdbs snippet, sue to internal 
limitations of the cdbs snippet (I am author of that code and am working 
on fixing this limitation, but it is is a slooow process as it needs to 
be done very careful to not break existing users of the tool).

...elaborating above just in case you stumble into similar stuff later 
on, because yes, below proposed package renaming+split should make the 
default DEB_PYTHON_MODULE_PACKAGES automagically work properly.

>python-* packages shouldn't install anything into /usr/sbin/ or 
>/usr/bin as far as I can tell, so just renaming rainbow to 
>python-rainbow would not be acceptable.

Python module packages _can_ contain other stuff than the module code 
itself, but I find it more elegant to keep things separate.

Yes, I like that renaming+split of binary packages (except for the 
versioned nss library, but we discuss that separately further up).

>> I suggest renaming *.md to *.mdwn (the extension used by e.g. Ikiwiki 
>> for Markdown files - I am not entirely sure that there is consensus 
>> about that extension, though).
>>
>
>There isn't much consensus, and pandoc uses .md in their examples.

Right you are (I have since engaged in pandoc packaging maintainance, 
and noticed this as well).

>> Did you write those Markdown files from scratch yourself, or did you 
>> bootstrap from data pulled from e.g. some web pages?  If so, it might 
>> make sense to setup a target in debian/rules to regenerate using 
>> newer upstream web sources.  Such target should not be used in normal 
>> builds (that's illegal!) but can be used by us to check once in a 
>> while if there are updated documentation.
>>
>
>I wrote them myself. I'm talking with Michael Stone to get those 
>integrated upstream.

Excellent, then :-)

Great work so far, Luke!

  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

   [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20091116/5e0b71d1/attachment.pgp>