FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-20-2010, 08:03 AM
Felix Kaechele
 
Default Query about usb_modeswitch and how to handle its packaging

Am 20.04.2010 09:55, schrieb Huzaifa Sidhpurwala:

> 2. Have two srpms one for data and one for binary, with both depending
> on each other.

This is the way to go. It also makes it easier for you to maintain it in
the future. However, you must create a new review request for the data
package then.

Felix
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-20-2010, 08:16 AM
Peter Robinson
 
Default Query about usb_modeswitch and how to handle its packaging

On Tue, Apr 20, 2010 at 8:55 AM, Huzaifa Sidhpurwala
<huzaifas@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi All,
> I maintain usb-modeswitch in fedora. Recently upstream divided the main
> tar ball into two parts, the code which builds into the usb_modeswitch
> binary and the data part which contains the udev rules.
>
> Initially there was just one tar ball with both, and my spec builds two
> rpms out of that namely usb_modeswitch and usb_modeswitch-data.
>
> Now upstream says that his intention of making two tar balls was to
> enable updating the data part more frequently then the code, which makes
> sense.
>
> Now i have two options:
>
> 1. Have just one srpm, which builds from the two tar balls, if that is
> done, the upstream purpose of updating the data more frequently is lost.
> Also upstream says usb_modeswitch has to depend on usb_modeswitch-data
> and vice versa.
> 2. Have two srpms one for data and one for binary, with both depending
> on each other.
>
> Which one do you think is the best option.
> Thanks in advance.

2 is definitely the best option as it allows to push updates to the
data package without the binary component.

You might want to look at how hal and hal-info does the deps cross check.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-20-2010, 08:16 AM
Peter Robinson
 
Default Query about usb_modeswitch and how to handle its packaging

On Tue, Apr 20, 2010 at 8:55 AM, Huzaifa Sidhpurwala
<huzaifas@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi All,
> I maintain usb-modeswitch in fedora. Recently upstream divided the main
> tar ball into two parts, the code which builds into the usb_modeswitch
> binary and the data part which contains the udev rules.
>
> Initially there was just one tar ball with both, and my spec builds two
> rpms out of that namely usb_modeswitch and usb_modeswitch-data.
>
> Now upstream says that his intention of making two tar balls was to
> enable updating the data part more frequently then the code, which makes
> sense.
>
> Now i have two options:
>
> 1. Have just one srpm, which builds from the two tar balls, if that is
> done, the upstream purpose of updating the data more frequently is lost.
> Also upstream says usb_modeswitch has to depend on usb_modeswitch-data
> and vice versa.
> 2. Have two srpms one for data and one for binary, with both depending
> on each other.
>
> Which one do you think is the best option.
> Thanks in advance.

2 is definitely the best option as it allows to push updates to the
data package without the binary component.

You might want to look at how hal and hal-info does the deps cross check.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org