Re: [opensuse-packaging] Multiple RPM's owning the same file

2008-01-09 Thread Lars Vogdt
On Mittwoch, 9. Januar 2008 19:01:27 Dan Stromberg wrote:
> We want to automate our install as much as possible, and some here
> believe that rpm is the right way to automate it, including rpm file
> dual ownership.
>
> For example, we want to throw a getty on ttyS0 - for that we need to
> change /etc/inittab.  The approach so far has been to replace
> /etc/inittab.  I'm now trying to gently pitch changing it from a post
> and postun.

I would prefer autoyast, but I like to show you two other possible 
options:

Alternatively, you can add the files as "normal" files in the filelist 
of your package (without %config) - So they're no config files any 
longer and would not be updated by the original RPM. But this also 
implements, that user changes are lost if you update _your_ package. 
(You can perhaps fix this in the %pre and %post with md5sum comparison 
or something else -- re-implement the wheel...) => ugly, but works for 
config files ;-)

Or try to re-package the rpms you need containing "your" settings. This 
means: 
* watch for updates of the main package (and rebuild your own)
* import your own gpg-key to the user machine

Regards,
 Lars
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-packaging] Which dependencies should I set?

2007-12-06 Thread Lars Vogdt
On Donnerstag, 6. Dezember 2007 03:48:17 Cristian Rodríguez wrote:
> Christian Boltz escribió:
> > - php-mysql and/or php-pgsql? One of them is always unused, but you
> >   never know which one in advance (from RPM's POV)
>
> Both now provides php_any_db virtual package.

This is one step - but what about the databases themselves?
Currently MySQL provides mysql, PostGreSQL provides postgresql - what 
should a package recommend, which runs with both databases?

As  these two are the most supported databases in the open source world, 
we should perhaps also think about a virtual provides for this two at 
least. 

Whats the minimal SQL standard both support? 
Perhaps we can add a virtual provides like "Provides: SQL2" 
or "Provides: SQL-92" - so an application with a generic SQL interface 
just have to require a SQL-92 compatible database...

Regards,
Lars
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-packaging] prefix horde apps with horde-*

2007-12-03 Thread Lars Vogdt
Hi

On Samstag, 1. Dezember 2007 20:20:01 Marcus Hüwe wrote:
> what about if we prefix all horde applications with "horde-"?
> Example: horde -> horde
>  imp   -> horde-imp
>   ingo  -> horde-ingo
>   ...
> The idea is that it is obvious to the user that a package is a horde
> application. This naming change would only affect the "imp" package
> in the distribution. If you agree with this change I could rename
> the horde packages in the server:php:applications buildservice
> project too.
>
> What do you think?

Sounds like a good idea. Would even be great if you can provide 
a "HowTo" in the openSUSE-Wiki like it's even been there for 
http://en.opensuse.org/Kolab

If I remember correctly, the horde* packages need some special 
configuration steps after installation. And so the README.SuSE can be 
enhanced with a link to that URL. (The INSTALL file is IMHO a bit  
overcrowded as most of the file is not useful if you install the rpm.)

Regards,
Lars
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-packaging] insserving services

2007-10-28 Thread Lars Vogdt
On Fr 26 Okt 2007 22:12:49 CEST Jan Engelhardt  
<[EMAIL PROTECTED]> wrote:

-y sets START variables to “yes” by default. It is ignored if
  X-UnitedLinux-Default-Enabled is specified in the init script.
-Y forces setting the START variable to “yes”. This means the service is
  always activated regardless of the setting before an update.


Right, and how can that ideally fly without recompiling the package?
Trying to spin a suse derivate (makesusedvd) where apache should be
started by default.


What about creating a "dummy" package which prerequires apache and has
%fillup_and_insserv -Y apache ?

Other solution: use AutoYast (because this is what autoyast is for)...

Greetings,
Lars

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[opensuse-packaging] Adding users and groups in %pre

2007-07-24 Thread Lars Vogdt
Hi

I think we also need a "global" decision about $ubject.
(See https://bugzilla.novell.com/show_bug.cgi?id=294188 for details.)

Currently each package handles this part separately - and I think we 
need a macro or a policy to unify this. 

Perhaps replacing the "useradd" and "groupadd" commands with a macro 
which understands the same options but handles the complete process in 
a more "secure" way (also think about server admins using LDAP, winbind 
or something else as database)...

Any other proposals?

Regards,
Lars
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-packaging] Building packages with linking a license from licenses.rpm

2007-07-24 Thread Lars Vogdt
Am Dienstag, 24. Juli 2007 16:55 schrieb Stanislav Brabec:
> This is what I use just now in my packages:
>
> for FILE in COPYING COPYING.LIB ; do
> MD5SUM=$(md5sum $FILE | sed 's/ .*//')
> if test -f /usr/share/doc/licenses/md5/$MD5SUM ; then
> ln -sf /usr/share/doc/licenses/md5/$MD5SUM $FILE
> fi
> done
>
> If you will replace list in the first line by an argument, you have a
> macro.
> You can also use "shopt -s nullglob" and add complete list of
> possible names.

Thanks Stanislav !
Michael: is this something we can add as rpm macro in 10.3 ?


> Note that rpmlint check is incomplete and does not check less common
> names for license.
>
> And dangling check in the rpmlint is broken and reports each link to
> license as a dangling link.

=> bugzila, please... ;-)

Lars
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-packaging] Building packages with linking a license from licenses.rpm

2007-07-24 Thread Lars Vogdt
Hi

Am Dienstag, 24. Juli 2007 11:27 schrieb Johannes Meixner:
> > Could someone, please point me (us) to some documentation, howto?

Currently we just have:
http://en.opensuse.org/Licenses

But I talked to mrueckert some days bevore - we're thinking about a rpm 
macro _and_ an additional internal brp-check. As none of these both is 
done currently, any other ideas are very welcome!

Lars



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-packaging] old version of SPC online

2007-07-10 Thread Lars Vogdt
Am Dienstag, 10. Juli 2007 10:58 schrieb Martin Kudlvasr:
> ASAP was meant to be yesterday. The new version is already at
> http://opensuse.org/SUSE_Package_Conventions .
> Feel free to comment, edit  cooperate.

Thanks again!
I've added a first "draw" of a new section for RPM Changelog entries:
http://en.opensuse.org/SUSE_Package_Conventions/Changelogs

This is _no_final_ one - so please comment, edit, ... ;-)

Lars
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[opensuse-packaging] Handling rpmlintrc files in packages

2007-07-02 Thread Lars Vogdt
Hi Packagers

As we add more and more rpmlintrc-files to our packages to deal with 
rpmlint warnings and errors, I think we should clarify some things here 
and afterwards add a new chapter to the packagers manual and the 
rpmlint site on en.opensuse.org.

1) Name your rpmlintrc-file!

Please _do_not_ add a plain rpmlintrc file to your package! Think about 
installing multiple src.rpms on your system: the last rpmlintrc will 
win... (yes, we should discuss the "installing src.rpms in an extra 
directory" problematic - but not within this mail ;-)

So please follow the description on
http://en.opensuse.org/Packaging/RpmLint
and name your rpmlintrc file:
%{name}-rpmlintrc or
%{name}-%{version}-rpmlintrc

2) Add your rpmlintrc file to your specfile

Please add a line like:
Source100: %{name}-%{version}-rpmlintrc
to your specfile. Otherwise both the check_if_valid_source_dir script 
will fail and autobuild will reject to check in your package.

Adding the rpmlintrc file as source will also add it to the src.rpm - so 
other packagers outsite can have a look at it and perhaps came up with 
a better solution. 

Any other/better suggestions about rpmlintrc-files are welcome!

Regards,
Lars



-- 
Lars Vogdt <[EMAIL PROTECTED]>
Autobuild Team
SUSE Linux Products GmbH GF: Markus Rex
Nuernberg, GermanyHRB 16746 (AG Nuernberg)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]