PDA

View Full Version : Packaging for openSUSE



wstephenson
2007-10-10, 05:07
Hi all

Just got my first squeezebox yesterday and am very happy with it.

I've repackaged SqueezeCenter svn for openSUSE and have a couple of questions

1) makerelease.pl builds an RPM using a simple specfile in platforms/redhat. How do you use the Debian and Fedora specfiles to build packages - are you dropping the tarball generated by makerelease.pl and the specfiles into a distro specific build service and turning the handle there?

2) Are you moving towards using distro perl instead of the included CPAN directory? The thread 'Nightly Builds broken on Windows' can be read to suggest that problems should be solved by upgrading distro perl packages. If so I'll have to improve my perl packaging skills.

3) Where/how are you distributing fedora/debian packages - the nightly RPM is apparently built with the simple redhat specfile - and are you aiming to get the redistributable parts upstream?

There is a switch in the fedora specfile to delete the Firmware and Graphics subdirs - are these the only unredistributable portions of the source tree? Are there (treading lightly here) any distributability issues I should know about with any binary code included in the repo?

I'll post a patch containing my changes when I get things cleaned up. At the moment I have edited slimserver.spec.build and hacked makerelease.pl to pass in suse-specific config and initscripts to the rpm build, but if there is another mechanism to build distro specific packages I'll use that instead.

4) Finally, the webapp does not respond and cries
[13:41:01.4112] Slim::Networking::Select::select (245) Error: Select task failed: Can't locate object method "canUseiTunesLibrary" via package "Slim::Plugin::iTunes::Common" (perhaps you forgot to load "Slim::Plugin::iTunes::Common"?) at /usr/lib/perl5/vendor_perl/5.8.8/Slim/Web/Settings/Server/Wizard.pm line 134.
- is this probably an svn blip or a packaging error on my part? /usr/lib/perl5/vendor_perl/5.8.8/Slim/Plugin/iTunes/Common.pm has the function, but I can't see a use iTunes anywhere in Wizard.pm.

Will Stephenson

andyg
2007-10-10, 06:37
On Oct 10, 2007, at 8:07 AM, wstephenson wrote:

>
> 1) makerelease.pl builds an RPM using a simple specfile in
> platforms/redhat. How do you use the Debian and Fedora specfiles to
> build packages - are you dropping the tarball generated by
> makerelease.pl and the specfiles into a distro specific build service
> and turning the handle there?

makerelease.pl has a separate section for Debian. We don't build
Fedora.

>
> 2) Are you moving towards using distro perl instead of the included
> CPAN directory? The thread 'Nightly Builds broken on Windows' can be
> read to suggest that problems should be solved by upgrading distro
> perl
> packages. If so I'll have to improve my perl packaging skills.

No, distro Perl packages cause too many problems. I've just moved
the Debian build back to using our CPAN directory. I know the Fedora
build depends on a bunch of distro Perl packages but I'm not going to
worry about it since we don't support it. If you can use distro
packages and still pass the minimum version checks I guess it's OK.

>
> 3) Where/how are you distributing fedora/debian packages - the nightly
> RPM is apparently built with the simple redhat specfile - and are you
> aiming to get the redistributable parts upstream?

What parts upstream? We have to distribute it ourselves because no
one else is allowed to redistribute the firmware.

>
> There is a switch in the fedora specfile to delete the Firmware and
> Graphics subdirs - are these the only unredistributable portions of
> the
> source tree? Are there (treading lightly here) any distributability
> issues I should know about with any binary code included in the repo?

I really don't understand why you would want to package SC only to
pull out these directories. Just don't bother, and let people
download it from us.

>
> I'll post a patch containing my changes when I get things cleaned up.
> At the moment I have edited slimserver.spec.build and hacked
> makerelease.pl to pass in suse-specific config and initscripts to the
> rpm build, but if there is another mechanism to build distro specific
> packages I'll use that instead.

OK, but it won't be applied, since we won't be supporting a SUSE build.

>
> 4) Finally, the webapp does not respond and cries
> [13:41:01.4112] Slim::Networking::Select::select (245) Error: Select
> task failed: Can't locate object method "canUseiTunesLibrary" via
> package "Slim::Plugin::iTunes::Common" (perhaps you forgot to load
> "Slim::Plugin::iTunes::Common"?) at
> /usr/lib/perl5/vendor_perl/5.8.8/Slim/Web/Settings/Server/Wizard.pm
> line 134.
> - is this probably an svn blip or a packaging error on my part?
> /usr/lib/perl5/vendor_perl/5.8.8/Slim/Plugin/iTunes/Common.pm has the
> function, but I can't see a use iTunes anywhere in Wizard.pm.

No idea, if the tarball works, it's probably a packaging problem.

wstephenson
2007-10-10, 08:29
Hi Andy! You sound a bit pre-coffee, but thanks for responding so quickly ;).



> makerelease.pl has a separate section for Debian. > We don't build
> Fedora.


So is someone external building Fedora or is the specfile just in the repo for the intrepid DIY fans?
Would you consider adding a suse build setup to SVN for others to roll their own with?



> No, distro Perl packages cause too many problems. > I've just moved the Debian build back to using our > CPAN directory. I know the Fedora build depends
> on a bunch of distro Perl packages but I'm not
> going to worry about it since we don't support it. > If you can use distro packages and still pass the
> minimum version checks I guess it's OK.


Fair enough, then I'll take the path of least resistance here and leave them inline.



What parts upstream? We have to distribute it ourselves because no
one else is allowed to redistribute the firmware.

I really don't understand why you would want to package SC only to
pull out these directories. Just don't bother, and let people download it from us.


I want to make my SqueezeCenter installation easy for me to maintain, and maybe in doing so make SC more accessible to the broader openSUSE community. I'd prefer to fix the packages then let people download them from you, but if you can't do that, an RPM that contains the redistributable parts in the openSUSE build service, and points users at the tarball for the firmware is the other option.



OK, but it won't be applied, since we won't be supporting a SUSE build.


There are some fixes in there that you should have in the generic RPM too.


No idea, if the tarball works, it's probably a packaging problem.

No worries, it was just a shot in the dark. I haven't tried the tarball yet.

andyg
2007-10-10, 08:57
On Oct 10, 2007, at 11:29 AM, wstephenson wrote:

> Andy Grundman;234058 Wrote:
>>
>>> makerelease.pl has a separate section for Debian. > We don't build
>>
>>> Fedora.
>>
>
> So is someone external building Fedora or is the specfile just in the
> repo for the intrepid DIY fans?
> Would you consider adding a suse build setup to SVN for others to roll
> their own with?

I don't know anything about the Fedora build. I wouldn't have a
problem adding a platforms/suse directory that is community-maintained.

> Andy Grundman;234058 Wrote:
>>
>> What parts upstream? We have to distribute it ourselves because no
>> one else is allowed to redistribute the firmware.
>>
>> I really don't understand why you would want to package SC only to
>> pull out these directories. Just don't bother, and let people
>> download
>> it from us.
>>
>
> I want to make my SqueezeCenter installation easy for me to maintain,
> and maybe in doing so make SC more accessible to the broader openSUSE
> community. I'd prefer to fix the packages then let people download
> them from you, but if you can't do that, an RPM that contains the
> redistributable parts in the openSUSE build service, and points users
> at the tarball for the firmware is the other option.

It's a lot of work for us to officially support a new distro package,
so I'm going to say for now that we won't be distributing a SUSE
package.

>
> Andy Grundman;234058 Wrote:
>>
>> OK, but it won't be applied, since we won't be supporting a SUSE
>> build.
>>
>
> There are some fixes in there that you should have in the generic RPM
> too.

OK, I have not yet taken a look at the status of our RPM build.

CatBus
2007-10-11, 09:06
I'll post a patch containing ... suse-specific config and initscripts to the rpm build, but if there is another mechanism to build distro specific packages I'll use that instead.

OK, but it won't be applied, since we won't be supporting a SUSE build.


That comment got me wondering...

1) Does SlimDevices/Logitech believe that there is any difference between "making XXX work" and "supporting XXX"? If a fringe distro just happens to work with the existing RPM, does this mean that distro is supported? I guess my point is I don't see the logical connection between applying a SUSE patch and supporting a SUSE build.

2) I'm all for rejecting patches that either break or risk breaking existing functionality (and I haven't seen this hypothetical patch, so I can't say), but rejecting patches that break nothing and improve compatibility seems like, well, the start of a code fork. I know SlimServer is GPL, but if a third-party began distributing an "improved" SlimServer RPM that worked on more distros than the trunk builds, could they distribute the player firmware in that RPM?

andyg
2007-10-11, 09:14
On Oct 11, 2007, at 12:06 PM, CatBus wrote:

>
>>>>> I'll post a patch containing ... suse-specific config and
>>>>> initscripts to
>>> the rpm build, but if there is another mechanism to build distro
>>> specific packages I'll use that instead.> >
>>
>> OK, but it won't be applied, since we won't be supporting a SUSE
>> build.
>>
>
> That comment got me wondering...
>
> 1) Does SlimDevices/Logitech believe that there is any difference
> between "making XXX work" and "supporting XXX"? If a fringe distro
> just happens to work with the existing RPM, does this mean that distro
> is supported? I guess my point is I don't see the logical connection
> between applying a SUSE patch and supporting a SUSE build.

To me, supporting means:
* building a nightly for that distro
* tech support needs to be prepared to handle calls for users of that
distro
* QA testing for that distro

>
> 2) I'm all for rejecting patches that either break or risk breaking
> existing functionality (and I haven't seen this hypothetical patch, so
> I can't say), but rejecting patches that break nothing and improve
> compatibility seems like, well, the start of a code fork. I know
> SlimServer is GPL, but if a third-party began distributing an
> "improved" SlimServer RPM that worked on more distros than the trunk
> builds, could they distribute the player firmware in that RPM?

No, the firmware can only be distributed by us.

CatBus
2007-10-11, 11:06
Ah, I think I have the distinction I was looking for--

- If someone committed a patch that required a separate RPM build, then SD/Logitech would need to build/QA that RPM. Makes sense, and I'd call that support.

- If someone committed a patch that allowed the existing RedHat RPM to install on SUSE without breaking it on RedHat, SD/Logitech would not need to make or QA a different build. I would not call that "supporting SUSE", I'd just call that "works with SUSE"

So a patch of the first type would not be committed, I understand. What about a patch of the second type?

andyg
2007-10-11, 11:56
On Oct 11, 2007, at 2:06 PM, CatBus wrote:

>
> Ah, I think I have the distinction I was looking for--
>
> - If someone committed a patch that required a separate RPM build,
> then
> SD/Logitech would need to build/QA that RPM. Makes sense, and I'd
> call
> that support.
>
> - If someone committed a patch that allowed the existing RedHat RPM to
> install on SUSE without breaking it on RedHat, SD/Logitech would not
> need to make or QA a different build. I would not call that
> "supporting SUSE", I'd just call that "works with SUSE"
>
> So a patch of the first type would not be committed, I understand.
> What about a patch of the second type?

Yep, that sounds right to me. A patch of the second type should be
fine.

bpa
2007-10-11, 12:46
Since distribution of firmware can only be done by SD/Logitech - what is the position wrt to the Slimserver packages for NASs such as QNAP, Thecus or Synology ?

andyg
2007-10-11, 12:49
Those NAS packages should not distribute firmware, and it will be downloaded from us on first startup.

CatBus
2007-10-11, 13:58
Thanks Andy. You're always very helpful.

wstephenson
2007-10-11, 14:32
On Oct 11, 2007, at 2:06 PM, CatBus wrote:

>
> Ah, I think I have the distinction I was looking for--
>
> - If someone committed a patch that required a separate RPM build,
> then
> SD/Logitech would need to build/QA that RPM. Makes sense, and I'd
> call
> that support.
>
> - If someone committed a patch that allowed the existing RedHat RPM to
> install on SUSE without breaking it on RedHat, SD/Logitech would not
> need to make or QA a different build. I would not call that
> "supporting SUSE", I'd just call that "works with SUSE"
>
> So a patch of the first type would not be committed, I understand.
> What about a patch of the second type?

Yep, that sounds right to me. A patch of the second type should be
fine.

But is a unified package for any moderately complex software at all possible? There are variations (even between FHS conformant distros) such as initrddir, log dir location, how to start daemons, that are generally handled at package build time. The existing RPM doesn't work on installation unless parts of it are replaced.

As an absurd example, if one were to write an specfile with complex scripts to detect distro at install time and put the right thing in the right location, any QA guarantees unless would be worthless for unless it were tested on all targets. Moving things around post-install and installing eg a different initscript would also invalidate RPM's verification data.

Since the 'second type' of package can't exist (please, prove me wrong) I'd like to suggest a 'third type' of package distribution, between 'SD/Logitech supported' and 'we'll host the specfile in svn, but we'll deny knowledge of any packages built with that': 'built externally, SD/Logitech hosted (or just link to an external repo) but UNSUPPORTED'. This would be easy for users to find, but, assuming that they read the disclaimer, no harder for SD/Logitech to support other than providing a bit of bandwidth.

CatBus
2007-10-11, 15:26
But is a unified package for any moderately complex software at all possible?

That's a valid question and the answer is probably no. But we're not talking about some generic abstract "moderately complex software"--we're talking very specifically about SlimServer. Either it can be done or it can't--the only way to find out is to try.

I really sympathize--I'm a longtime SUSE user and have no plans to switch to any other distro in the forseeable future. I agree it's a real pain to have to hand-create init files, permissions, runlevels, etc when I install SlimServer. But frankly if a third-party software vendor can't make a single RPM that works on most distros, that's a problem the FHS/LSB standards need to address. Maybe someday the level of standardization will exist such that third-party vendors can support Linux more easily--that would be the best solution for all involved.

If it turns out a cross-distro RPM can't be made, then the only solutions are:
1) Go with the status quo. Keep the SUSE wiki up-to-date and people will just need to fix the SlimServer installs themselves.
2) Try to convince Logitech/SlimDevices that they should devote some (maybe not many, but some) resources to SUSE packaging. I think it's safe to say that's an uphill battle.
3) Create, maintain, and distribute your own RPM (or convince Novell/openSUSE/someone else to do it). The firmware problem can be worked around as Andy suggested--don't distribute the firmware within the RPM, but have SlimServer download the firmwares when it starts.

s/SlimServer/SqueezeCenter/g on that whole post. Still having a hard time getting used to that.

wstephenson
2007-10-12, 00:37
That's a valid question and the answer is probably no. But we're not talking about some generic abstract "moderately complex software"--we're talking very specifically about SlimServer. Either it can be done or it can't--the only way to find out is to try.

I really sympathize--I'm a longtime SUSE user and have no plans to switch to any other distro in the forseeable future. I agree it's a real pain to have to hand-create init files, permissions, runlevels, etc when I install SlimServer. But frankly if a third-party software vendor can't make a single RPM that works on most distros, that's a problem the FHS/LSB standards need to address. Maybe someday the level of standardization will exist such that third-party vendors can support Linux more easily--that would be the best solution for all involved.


It's a nice idea, but not feasible yet. Above the level of shared filesystem hierarchies and compatible config and init scripts there are still multiple package management systems.

The openSUSE project is developing the Build Service to reduce the cost and complexity of maintaining a cross-distro and -platform build and packaging software, and tools like the debian importer to automate creating specfiles from another distro's existing packaging control files.


If it turns out a cross-distro RPM can't be made, then the only solutions are:
1) Go with the status quo. Keep the SUSE wiki up-to-date and people will just need to fix the SlimServer installs themselves.
We can do better than that.

2) Try to convince Logitech/SlimDevices that they should devote some (maybe not many, but some) resources to SUSE packaging. I think it's safe to say that's an uphill battle.
I'd like to convince SD/Logitech that I can handle the packaging, and maybe make the building part go away too. Then maybe distribute or link to the resulting packages.


3) Create, maintain, and distribute your own RPM (or convince Novell/openSUSE/someone else to do it). The firmware problem can be worked around as Andy suggested--don't distribute the firmware within the RPM, but have SlimServer download the firmwares when it starts.

This is my fallback position. Does the firmware download mechanism already exist? If I create an RPM with an empty, slimserver-writeable Firmware directory, will it check and save the firmware there?

Will

bpa
2007-10-12, 01:00
Does the firmware download mechanism already exist? If I create an RPM with an empty, slimserver-writeable Firmware directory, will it check and save the firmware there?


The code is there and it seems to work as long as the version files are in the directory Firmware.

wstephenson
2007-10-12, 02:10
That works, thanks for the pointer.

CatBus
2007-10-12, 09:09
Good luck. I hope you succeed so well that it helps convince SD/Logitech that they should take a second look at SUSE. Keep us posted, here and in the SUSE wiki.

Mark Miksis
2007-10-12, 11:02
So is someone external building Fedora or is the specfile just in the repo for the intrepid DIY fans?

I was one of the two community members involved in the "fedora" specfile. The original objective was to remove the CPAN directory, get the perl modules from other repos and provide a spec file back to SD that could be used to host a slimserver yum repo.

Sadly, we never finished because:
1) We both ran out of time to contribute.
2) Using external repos for perl modules became a big mess because the required modules weren't available from a single place (and many weren't available anywhere). (As Andy mentioned, SD has also given up on this for Debian.)

The current state of our work is still at http://svn.slimdevices.com/trunk/platforms/fedora/ and a test yum repo (never updated) is at http://repos.slimdevices.com/yum/slimserver-testing/.

Despite the failure of the external perl module idea, I think we made some other useful changes to the specfile. Specifically:
- Modify install locations for FHS compatibility
- Build the RPM from the official public tarball, not a munged one
- Require: the system's copy of mysqld
- Add support for logrotate
- Lots of cleanup to the %pre and %post scriptlets
- Minor cleanup of the init and sysconfig file
- Maybe others...
If SD is interested and no one is already doing it, I plan to "backport" these changes to a new 7.0 spec file.

I've never used SUSE, but anyone interested in making a "universal" RPM should probably have a look at this article: http://www.novell.com/coolsolutions/feature/11256.html.

CatBus
2007-10-12, 11:05
Holy damn. Fletch you are my hero.