Hi,

> - when updating an existing port, is it recommended to copy in your own depot
> (own user) or work on the existing one (as root)? in the first case, it
> seems that not all action are prioritizing repositories in the same order
> (install and before).

I'd recommend copying it so
 (1) you can generate a unified diff for submission
 (2) you don't accidentally lose your changes with the next selfupdate


> - there is a startupitem option but it does not seem any way to include a
> cron-like job through launchd? script/exec to launch every day/month. So I
> suppose for now, we include our own file.

There's no option to do that with the startupitem.* options, but you can 
provide your own launchd plist. See the mpstats port in my user directory [1] 
that does exactly that (along with randomizing the execution time).


> - but in this case, what is the variable for the <port>/files dir. or files
> is supposed to be only patchfiles?

You can put any file you need there, as the mpstats ports does. $filespath is 
the variable you're looking for.


> - any way to reinplace w a newline?
> tried the following and failed (but it seems depending on which sed, there
> are different options)
> stackoverflow.com/questions/6111679/insert-linefeed-in-sed-mac-os-x
> \\\n
> \\`echo -e '\n\r'`

I don't know about that one, sorry.


> - the official packages are signed, right? as
> http://blog.infobytesec.com/2011/07/pwning-mac-os-x-with-evilgrade-macports.html

This attack is no longer possible. The ports tree containing the hash values, 
the base tarball for selfupdate, the MacPorts installer and the binary packages 
are signed.


> For your own repository, there is
> https://trac.macports.org/wiki/archives

That and https://trac.macports.org/wiki/howto/ShareArchives2


> There is also for pkg/mpkg (not sure if still valid)
> http://trac.macports.org/ticket/30562

pkg and mpkg packages are currently not signed automatically by MacPorts. You 
can sign them manually just like you'd sign installers if you have the 
necessary certificates from Apple (i.e. the Mac Dev program). In fact, that's 
how the MacPorts installers are created.
MacPorts does also not automatically sign the binary archives it builds and 
internally used. Our buildbots use 
http://trac.macports.org/browser/contrib/buildbot/deploy_archives.sh to do that.


> - any option/script mirror macports install. something like
> port installed requested --dump mylist
> port install --load mylist

I guess you can use port installed -q requested and write a script to call port 
install for this list. See 
https://trac.macports.org/browser/contrib/restore_ports/restore_ports.tcl which 
does something similar.


> - I have few ports which reacts differently in macports call than manually
> (firebird, beltane)
> They are not building in macports but if I launch manually the command in
> ${worksrcdir}, it's ok.
> I tried to look to env var but nothing found for now.

That might be due to a lot of reasons like sandboxing, privilege separation, 
etc.; without a main.log it's unlikely anybody will be able to help you.


> - is there some test framework/command, so I can ask: for all my repository,
> compile ports and all variants up to destroot and report any errors.

No, no such thing exists.


> - is it necessary for python/perl/web modules to "Updating database of
> binaries / Scanning binaries for linking errors:" ?

The updating database of binaries is always necessary, the other wouldn't be 
necessary in theory, but MacPorts will always run it after install/upgrade by 
default. You can turn that off in macports.conf, if you want.


> - any example of library which have both lib and python-bindings? do we try
> to make subport or not?

Can't help you there either, sorry. Somebody else might be able to.


> - for now, there is now test section in Portfile to ensure it is running
> correctly at least for some commands, right? (like calling 'make tests' or a
> defined exec)

To call "make tests" when sudo port test $portname is run, put the following in 
a Portfile:

test.run yes
test.target tests
# test.cmd make (defaults to ${build.cmd}, which often is make)


[1] http://trac.macports.org/browser/users/cal/ports/macports/mpstats

-- 
Clemens Lang
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to