Re: Separating packages.
On Mon, 2004-04-05 at 12:24, n.v.t n.v.t wrote: > package-backgrounds > package-icons > package-examples > package-name (which contains all of the above) Should I do this as a > meta-package? How do I create a meta-package? I don't think you need a meta package. I would do this to allow flexibility and save space: package * Contains all the files not in the other packages. * Depends on -backgrounds, -icons, and -examples (or only those required, you may want to leave out -examples from the dependency list). package-backgrounds * Contains backgrounds. * May be installed separately (no dependencies). package-icons * Contains icons. * May be installed separately (no dependencies). package-examples * Contains examples. * Depends on package. Make sure the user gets the expected result when installing only one of these. > How do I handle dependencies of the icon's e.g? There is a Makefile in the > directories that speaks of a view binaries. Should I create a separated > section in the 'control' file? What do I put in the 'rules' file? The control file should reflect the split you choose, by listing all the packages and their dependencies according to your plan. The rules file should build the package, and then split out the files into the separate package directories. For a simple example, you can look at the albatross package (in unstable). It should be quite simple to follow. It's a python package though, so there may be some things mandated by python policy that doesn't apply to your package. Also, any other split package is a good source of information. apt-get source and debhelper are your friends. Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
From: Fabian Fagerholm <[EMAIL PROTECTED]>
To: "n.v.t n.v.t" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: Separating packages.
Date: 05 Apr 2004 13:05:45 +0300
On Mon, 2004-04-05 at 12:24, n.v.t n.v.t wrote:
> package-backgrounds
> package-icons
> package-examples
> package-name (which contains all of the above) Should I do this as a
> meta-package? How do I create a meta-package?
I don't think you need a meta package. I would do this to allow
flexibility and save space:
package
* Contains all the files not in the other packages.
* Depends on -backgrounds, -icons, and -examples (or only those
required, you may want to leave out -examples from the
dependency list).
package-backgrounds
* Contains backgrounds.
* May be installed separately (no dependencies).
package-icons
* Contains icons.
* May be installed separately (no dependencies).
package-examples
* Contains examples.
* Depends on package.
Aha, okay, this sounds okay.
Make sure the user gets the expected result when installing only one of
these.
> How do I handle dependencies of the icon's e.g? There is a Makefile in
the
> directories that speaks of a view binaries. Should I create a separated
> section in the 'control' file? What do I put in the 'rules' file?
The control file should reflect the split you choose, by listing all the
packages and their dependencies according to your plan.
The rules file should build the package, and then split out the files
into the separate package directories.
For a simple example, you can look at the albatross package (in
unstable). It should be quite simple to follow. It's a python package
though, so there may be some things mandated by python policy that
doesn't apply to your package. Also, any other split package is a good
source of information.
What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
meaning of those in the debian policy either? Why not just put depends of
the splited package in the depends line instead of this?
apt-get source and debhelper are your friends.
Cheers,
Joe
--
Fabian Fagerholm <[EMAIL PROTECTED]>
_
MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > I have simple question which I could not find in the debian policy, maybe > someone could point me out to that section or the right documentation? Or a > explanation would be nice. I'm debianizing a package that I would like to > split up in several parts, the package has a 'backgrounds' directory a > 'icons' directory and a 'examples' directory. How do I handle this? I would > like to create packages like: > > package-backgrounds > package-icons > package-examples > package-name (which contains all of the above) Should I do this as a > meta-package? How do I create a meta-package? [...] Why? How big are the components? Would somebdy e.g install package-name without package-icons or the other way round? cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
From: Andreas Metzler <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Separating packages.
Date: Mon, 5 Apr 2004 14:31:43 +0200
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote:
> I have simple question which I could not find in the debian policy,
maybe
> someone could point me out to that section or the right documentation?
Or a
> explanation would be nice. I'm debianizing a package that I would like
to
> split up in several parts, the package has a 'backgrounds' directory a
> 'icons' directory and a 'examples' directory. How do I handle this? I
would
> like to create packages like:
>
> package-backgrounds
> package-icons
> package-examples
> package-name (which contains all of the above) Should I do this as a
> meta-package? How do I create a meta-package?
[...]
Why? How big are the components? Would somebdy e.g install package-name
without package-icons or the other way round?
cu andreas
It was a example. The person might only want the backgrounds or only the
icons.
package
* Contains all the files not in the other packages.
* Depends on -backgrounds, -icons, and -examples (or only those
required, you may want to leave out -examples from the
dependency list).
package-backgrounds
* Contains backgrounds.
* May be installed separately (no dependencies).
package-icons
* Contains icons.
* May be installed separately (no dependencies).
package-examples
* Contains examples.
* Depends on package.
Sounds better to me.
What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
meaning of those in the debian policy either? Why not just put depends of
the splited package in the depends line instead of this?
This question still remains open to me.
Joe
_
MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Mon, 2004-04-05 at 14:55, n.v.t n.v.t wrote:
> What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
> meaning of those in the debian policy either? Why not just put depends of
> the splited package in the depends line instead of this?
You can manually enter the dependencies of each package, that's fine --
but it could be a lot of work for a human. Debhelper is there to help
you.
${shlibs:Depends} and ${misc:Depends} are documented in the debhelper
documentation [0]. Basically, ${misc:Depends} tells debhelper to insert
dependencies for packages that you need because you have used some
debhelper feature. ${shlibs:Depends} is a debhelper program that
generates a shlibs file for shared libraries.
They are useful because they will save you some typing, and if something
changes in debhelper or in your package, you don't have to work out the
dependencies manually -- debhelper will take care of it for you.
Of course, if you don't use debhelper in your package (you should :) or
if your package doesn't have shared libraries, then you don't need
these. There are other such substitution variables, such as
${perl:Depends} for perl packages, and ${python:Depends} for python
packages.
[0] Type "man debhelper".
Cheers,
--
Fabian Fagerholm <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: Separating packages.
On Mon, Apr 05, 2004 at 06:11:57PM +0300, Fabian Fagerholm wrote:
> On Mon, 2004-04-05 at 14:55, n.v.t n.v.t wrote:
> > What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
> > meaning of those in the debian policy either? Why not just put depends of
> > the splited package in the depends line instead of this?
>
> You can manually enter the dependencies of each package, that's fine --
> but it could be a lot of work for a human. Debhelper is there to help
> you.
>
> ${shlibs:Depends} and ${misc:Depends} are documented in the debhelper
> documentation [0]. Basically, ${misc:Depends} tells debhelper to insert
> dependencies for packages that you need because you have used some
> debhelper feature. ${shlibs:Depends} is a debhelper program that
> generates a shlibs file for shared libraries.
Actually, ${shlibs:Depends} is implemented by dpkg-shlibdeps, in
dpkg-dev. dh_shlibdeps in debhelper is a trivial wrapper around it.
> Of course, if you don't use debhelper in your package (you should :) or
> if your package doesn't have shared libraries, then you don't need
> these.
Every package containing dynamically linked binaries should use
${shlibs:Depends}.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
Hi, Ok, that seems to be all clear to me, what about the rules file? How do I separate packages, the example that Andreas Metzler told me to check out, doesn't clear things entirely. Is this the way we should learn it, by examples? So I move files into a directory then create a deb out of each package? A " make " (destdir or something similar like that?) parameter, how should this be done? What am I missing here? Please cc me, I'm not subscribed. Joe _ MSN Zoeken helpt je om de gekste dingen te vinden! http://search.msn.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
I'm sorry I forgot to give a example , the structure of the packge looks like this: dir/icon dir/backgrounds dir/examples They all have a Makefile ofcourse in each directory. Joe _ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Monday 05 April 2004 14:31, Andreas Metzler wrote: > On Mon, Apr 05, 2004 at 09:24:10AM +, WHAT'SYOURNAME wrote: > > I'm debianizing a package that I would like to split up, like: > > package-backgrounds > > package-icons > > package-examples > > Why? How big are the components? Would somebdy e.g install > package-name without package-icons or the other way round? >cu andreas Contemplate debian-policy 11.8: Programs for the X Window System. (It is clearer, wrt. to your question, in older policy versions). No micro management of components that are installed together anyway. (Dpkg has to read the whole database on every system every time;). I have (taken over) such a package, and while it even makes some sense with that specific pkg, which is why i haven't changed it yet, it is a constant pain for me and users of it - i know what i tell you about ;-) Have a nice day, martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > Hello all. > > I have simple question which I could not find in the debian policy, maybe > someone could point me out to that section or the right documentation? Or a > explanation would be nice. I'm debianizing a package that I would like to > split up in several parts, the package has a 'backgrounds' directory a > 'icons' directory and a 'examples' directory. How do I handle this? I would > like to create packages like: > > package-backgrounds > package-icons > package-examples > package-name (which contains all of the above) Should I do this as a > meta-package? How do I create a meta-package? Is it really necessary to split it up like this? What is gained by placing the icons and backgrounds in separate packages? If the program isn't useful without this data, then it should be included in the same package with the program, unless (for example) it is very large and could benefit from being moved into an architecture: all package. Even in that case, do the backgrounds and icons need to be separate? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Mon, Apr 05, 2004 at 12:57:55PM +, n.v.t n.v.t wrote: > >Why? How big are the components? Would somebdy e.g install package-name > >without package-icons or the other way round? > > It was a example. The person might only want the backgrounds or only the > icons. This alone is not sufficient reason for producing four packages instead of one. This wastes resources in many places (the Debian package list, the dpkg database, etc.). You must consider whether the benefit is worth the cost. Certainly, the user might only want some of the things in the package. But would it hurt him to have all of it? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Mon, 2004-04-05 at 20:16, n.v.t n.v.t wrote: > Ok, that seems to be all clear to me, what about the rules file? How do I > separate packages, the example that Andreas Metzler told me to check out, > doesn't clear things entirely. Is this the way we should learn it, by > examples? So I move files into a directory then create a deb out of each > package? A " make " (destdir or something similar like that?) parameter, how > should this be done? What am I missing here? This is perhaps the most difficult thing to understand about Debian packaging. It's implied in several places, and it's briefly spelt out in some other places, but in general, you are referred to "examples" which vary as much as the packages in the Debian archive. In basic terms, when you build a package, the files generated by the build process are placed in debian/packagename, a directory which is generated by the build tools (they look at the control file for the names). The contents of that directory corresponds to the contents of the deb package "packagename". This means that if you place a file in debian/packagename, it will show up in the package. So what you need to do is make sure the right files end up in the right debian/packagename directory. Because it's a good idea to use debhelper, you should use dh_install to move the files in place. You said you have the following structure: dir/icon dir/backgrounds dir/examples So, in the build target of the rules file, you run the makefile for each of these (or if another makefile already does that, you may omit it, it depends on how the upstream build system is constructed). Now, your package probably comes with an install script that will install the files in their correct destinations. Let's say the package installs the icons, backgrounds and examples using a structure as described above. Then you need to dh_install the contents of each directory into the correct debian/packagename directory. You do this (for example) by saying something like dh_install -ppackagename dir/icon dir/in/package in the install target of the rules file. Here, dir/icon is relative to the source directory (the directory containing debian/ and upstream's sources). Read man dh_install for the complete details. You can then remove the unneccessary directories from the main package (with rm). Another way, which may be better because it reduces the chance that you include a file which wasn't meant to be included, is to have the package install into debian/tmp. Then you dh_install each file and directory into the appropriate package. debian/tmp is then removed in the clean target along with any unneccessary stuff. You have received responses pointing out that there are many important subtleties to be considered when making a split package. You should consider them good advice. I'm just explaining "how to do it" because I found this to be the most difficult thing to understand about deb packaging (probably because it's so simple :) -- but I haven't said anything about "why you should or shouldn't do it". Hope this clears things out for you! Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Tue, 2004-04-06 at 08:45, Matt Zimmerman wrote: > This alone is not sufficient reason for producing four packages instead of > one. This wastes resources in many places (the Debian package list, the > dpkg database, etc.). You must consider whether the benefit is worth the > cost. Of course, with the current version of dpkg, your point is very good and entirely valid. Thinking ahead, wouldn't it be a good idea to fix dpkg and the package list to support a larger number of packages? The number of packages in Debian has been constantly growing, and if I'm not mistaken, a release of sarge would include somewhere between 1 and 15000 packages. A presumptive sarge+1 could very well have much more than 15000 packages. If sarge is released any time soon, then a few split packages won't be a big deal. If it isn't, there will certainly be a lot more packages in testing, perhaps enough to require this change of dpkg and the package list anyway. So is the cost really that great? Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
* Fabian Fagerholm <[EMAIL PROTECTED]> [040405 12:10]: > I don't think you need a meta package. I would do this to allow > flexibility and save space: > > package > * Contains all the files not in the other packages. > * Depends on -backgrounds, -icons, and -examples (or only those > required, you may want to leave out -examples from the > dependency list). I suggest recommends or suggests here. If it is really a depend, then they should be in the same package. Even recommend sounds a bit strong for things like that. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Tue, 2004-04-06 at 11:49, Bernhard R. Link wrote: > > package > > * Contains all the files not in the other packages. > > * Depends on -backgrounds, -icons, and -examples (or only those > > required, you may want to leave out -examples from the > > dependency list). > > I suggest recommends or suggests here. If it is really a depend, then > they should be in the same package. Even recommend sounds a bit strong > for things like that. Why? If the data packages are useful on their own, and if they are sufficiently large, then a split is certainly a good idea -- at least from the user's point of view. But if the main package depends on the data, then not having a depends-relationship would break the software. I'm sure that's the least desirable option? Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Tue, Apr 06, 2004 at 08:18:55AM -0400, Erik Bourget wrote: > Fabian Fagerholm <[EMAIL PROTECTED]> writes: > > > > > Thanks! (to you and everyone who pitched in). d-m is really friendly. Because Fabian wrote: > This is perhaps the most difficult thing to understand about Debian > packaging. It's implied in several places, and it's briefly spelt out in > some other places, but in general, you are referred to "examples" which > vary as much as the packages in the Debian archive. Maybe it's an idea to improve the available documents? (thinking NM guide) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Tue, Apr 06, 2004 at 11:29:54AM +0300, Fabian Fagerholm wrote: > Of course, with the current version of dpkg, your point is very good and > entirely valid. > > Thinking ahead, wouldn't it be a good idea to fix dpkg and the package > list to support a larger number of packages? The problem with the package list is simply that it is too large. This is a problem for low-bandwidth users and users with small amounts of memory, for example. It also makes package management UIs harder to navigate, produces additional work for tools which must process each binary package, makes package searches less likely to find the right thing... > The number of packages in Debian has been constantly growing, and if I'm > not mistaken, a release of sarge would include somewhere between 1 and > 15000 packages. A presumptive sarge+1 could very well have much more than > 15000 packages. Yes, we have more than enough growth from adding new software; there is no need to compound the problem with unnecessary splits. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Tue, 2004-04-06 at 07:42, Matt Zimmerman wrote: > On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > > > Hello all. > > > > I have simple question which I could not find in the debian policy, maybe > > someone could point me out to that section or the right documentation? Or a > > explanation would be nice. I'm debianizing a package that I would like to > > split up in several parts, the package has a 'backgrounds' directory a > > 'icons' directory and a 'examples' directory. How do I handle this? I would > > like to create packages like: > > > > package-backgrounds > > package-icons > > package-examples > > package-name (which contains all of the above) Should I do this as a > > meta-package? How do I create a meta-package? > > Is it really necessary to split it up like this? What is gained by placing > the icons and backgrounds in separate packages? Hi, This all sounds to me like a complete theme package. Does this package also contains gtk themes? If so, then it would be a good idea to separate the gtk and gtk2 themes. But from what I don't understand is why do you want to separate the backgrounds/icons/examples from each other? I debianizing the redhat-artwork (not for the official repository) but for personal gain and experience. What are you trying to package? Arvind Arvind Autar | GnuPG-Key ID: 336E5788 Key fingerprint = FAB8 B3E5 0059 880A 00B8 C859 350E BBDC 336E 5788 signature.asc Description: This is a digitally signed message part
Re: Separating packages.
On Tue, 2004-04-06 at 18:38, Matt Zimmerman wrote: > The problem with the package list is simply that it is too large. This is a > problem for low-bandwidth users and users with small amounts of memory, for > example. > > It also makes package management UIs harder to navigate, produces additional > work for tools which must process each binary package, makes package > searches less likely to find the right thing... I'm inclined to believe that there are some things that could be done about this if someone wanted to. Diffs for the package list has been proposed, and it doesn't take many minutes of thinking to see that it's actually quite possible to do for a stable release (infrequent changes). Making the package database efficient for the purposes you describe is definitely not impossible either, even with a large list of packages. > Yes, we have more than enough growth from adding new software; there is no > need to compound the problem with unnecessary splits. From a usability perspective, the technical problems of the package management system are uninteresting. Presenting the packages in a well-organized, easily searchable way and letting the user choose what to install and what not to install is the primary goal. If splitting a package supports a group of users, and the split doesn't affect the needs of other groups of users, then I think "the package management system doesn't scale" is a bad excuse for not making the split. Unneccessary splits should of course be avoided, always. Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Separating packages.
On Wed, Apr 07, 2004 at 01:18:11PM +0300, Fabian Fagerholm wrote: > I'm inclined to believe that there are some things that could be done > about this if someone wanted to. Diffs for the package list has been > proposed, and it doesn't take many minutes of thinking to see that it's > actually quite possible to do for a stable release (infrequent changes). > Making the package database efficient for the purposes you describe is > definitely not impossible either, even with a large list of packages. Certainly there are things which could be done to help. I didn't say that the problems were insoluble, but they do exist, and you haven't even begun to consider them all (many different pieces of infrastructure are affected). > From a usability perspective, the technical problems of the package > management system are uninteresting. Presenting the packages in a > well-organized, easily searchable way and letting the user choose what to > install and what not to install is the primary goal. If splitting a > package supports a group of users, and the split doesn't affect the needs > of other groups of users, then I think "the package management system > doesn't scale" is a bad excuse for not making the split. That's the point, though; the split _does_ affect the needs of other groups of users (in many cases, nearly every user of Debian, even if they don't even realize the existence of the package), and the problems are not limited to "[some parts of] the package management system [don't] scale" (though that would be enough for a maintainer to consider). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Wed, 2004-04-07 at 19:45, Matt Zimmerman wrote: > Certainly there are things which could be done to help. I didn't say that > the problems were insoluble, but they do exist, and you haven't even begun > to consider them all (many different pieces of infrastructure are affected). Ok, I admit I haven't considered all the related problems. I probably know too little to be able to find them all. However, I'm then left with only one way to look at this: either this is a problem that cannot be solved, or the flaws that lead to this go deeper than I thought. If you're right and the problems are solvable, then this sure is one mammoth of a problem. Let me put it this way: disregarding the particulars of any package management system, doesn't it sound silly that you can't split packages when it would fit a purpose? If there is a non-technical reason, then there's no problem and the package shouldn't be split. But if the reason, however large and complicated, is technical, then that's no reason at all -- it's a challenge to be solved. Well, I realize that the next thing I'd have to do is to stop whining and write the code to solve all these problems and remove any technical obstacles to split every single file in all the Debian packages into a package per file. Maybe I will. Maybe someone else will. But I doubt it will be done as long as the approach is to value what we have more than what we could have... Anyway, interesting discussion. If anyone has any further information, I'd be glad to learn more about it! Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Separating packages.
On Tue, Apr 06, 2004 at 10:18:57AM +0200, Arvind Autar wrote: > On Tue, 2004-04-06 at 07:42, Matt Zimmerman wrote: > > On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > > > > > Hello all. > > > > > > I have simple question which I could not find in the debian policy, maybe > > > someone could point me out to that section or the right documentation? Or a > > > explanation would be nice. I'm debianizing a package that I would like to > > > split up in several parts, the package has a 'backgrounds' directory a > > > 'icons' directory and a 'examples' directory. How do I handle this? I would > > > like to create packages like: > > > > > > package-backgrounds > > > package-icons > > > package-examples > > > package-name (which contains all of the above) Should I do this as a > > > meta-package? How do I create a meta-package? > > > > Is it really necessary to split it up like this? What is gained by placing > > the icons and backgrounds in separate packages? > > Hi, > > This all sounds to me like a complete theme package. Does this package > also contains gtk themes? If so, then it would be a good idea to > separate the gtk and gtk2 themes. But from what I don't understand is > why do you want to separate the backgrounds/icons/examples from each > other? I debianizing the redhat-artwork (not for the official > repository) but for personal gain and experience. What are you trying to > package? I'm also curious about it, so this is a resend with it a CC to the unsubscribed original poster > > Arvind Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Mon, 2004-04-05 at 12:24, n.v.t n.v.t wrote: > package-backgrounds > package-icons > package-examples > package-name (which contains all of the above) Should I do this as a > meta-package? How do I create a meta-package? I don't think you need a meta package. I would do this to allow flexibility and save space: package * Contains all the files not in the other packages. * Depends on -backgrounds, -icons, and -examples (or only those required, you may want to leave out -examples from the dependency list). package-backgrounds * Contains backgrounds. * May be installed separately (no dependencies). package-icons * Contains icons. * May be installed separately (no dependencies). package-examples * Contains examples. * Depends on package. Make sure the user gets the expected result when installing only one of these. > How do I handle dependencies of the icon's e.g? There is a Makefile in the > directories that speaks of a view binaries. Should I create a separated > section in the 'control' file? What do I put in the 'rules' file? The control file should reflect the split you choose, by listing all the packages and their dependencies according to your plan. The rules file should build the package, and then split out the files into the separate package directories. For a simple example, you can look at the albatross package (in unstable). It should be quite simple to follow. It's a python package though, so there may be some things mandated by python policy that doesn't apply to your package. Also, any other split package is a good source of information. apt-get source and debhelper are your friends. Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]>
Re: Separating packages.
From: Fabian Fagerholm <[EMAIL PROTECTED]>
To: "n.v.t n.v.t" <[EMAIL PROTECTED]>
CC: debian-mentors@lists.debian.org
Subject: Re: Separating packages.
Date: 05 Apr 2004 13:05:45 +0300
On Mon, 2004-04-05 at 12:24, n.v.t n.v.t wrote:
> package-backgrounds
> package-icons
> package-examples
> package-name (which contains all of the above) Should I do this as a
> meta-package? How do I create a meta-package?
I don't think you need a meta package. I would do this to allow
flexibility and save space:
package
* Contains all the files not in the other packages.
* Depends on -backgrounds, -icons, and -examples (or only those
required, you may want to leave out -examples from the
dependency list).
package-backgrounds
* Contains backgrounds.
* May be installed separately (no dependencies).
package-icons
* Contains icons.
* May be installed separately (no dependencies).
package-examples
* Contains examples.
* Depends on package.
Aha, okay, this sounds okay.
Make sure the user gets the expected result when installing only one of
these.
> How do I handle dependencies of the icon's e.g? There is a Makefile in
the
> directories that speaks of a view binaries. Should I create a separated
> section in the 'control' file? What do I put in the 'rules' file?
The control file should reflect the split you choose, by listing all the
packages and their dependencies according to your plan.
The rules file should build the package, and then split out the files
into the separate package directories.
For a simple example, you can look at the albatross package (in
unstable). It should be quite simple to follow. It's a python package
though, so there may be some things mandated by python policy that
doesn't apply to your package. Also, any other split package is a good
source of information.
What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
meaning of those in the debian policy either? Why not just put depends of
the splited package in the depends line instead of this?
apt-get source and debhelper are your friends.
Cheers,
Joe
--
Fabian Fagerholm <[EMAIL PROTECTED]>
_
MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl
Re: Separating packages.
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > I have simple question which I could not find in the debian policy, maybe > someone could point me out to that section or the right documentation? Or a > explanation would be nice. I'm debianizing a package that I would like to > split up in several parts, the package has a 'backgrounds' directory a > 'icons' directory and a 'examples' directory. How do I handle this? I would > like to create packages like: > > package-backgrounds > package-icons > package-examples > package-name (which contains all of the above) Should I do this as a > meta-package? How do I create a meta-package? [...] Why? How big are the components? Would somebdy e.g install package-name without package-icons or the other way round? cu andreas
Re: Separating packages.
From: Andreas Metzler <[EMAIL PROTECTED]>
Reply-To: debian-mentors@lists.debian.org, [EMAIL PROTECTED]
To: debian-mentors@lists.debian.org
CC: [EMAIL PROTECTED]
Subject: Re: Separating packages.
Date: Mon, 5 Apr 2004 14:31:43 +0200
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote:
> I have simple question which I could not find in the debian policy,
maybe
> someone could point me out to that section or the right documentation?
Or a
> explanation would be nice. I'm debianizing a package that I would like
to
> split up in several parts, the package has a 'backgrounds' directory a
> 'icons' directory and a 'examples' directory. How do I handle this? I
would
> like to create packages like:
>
> package-backgrounds
> package-icons
> package-examples
> package-name (which contains all of the above) Should I do this as a
> meta-package? How do I create a meta-package?
[...]
Why? How big are the components? Would somebdy e.g install package-name
without package-icons or the other way round?
cu andreas
It was a example. The person might only want the backgrounds or only the
icons.
package
* Contains all the files not in the other packages.
* Depends on -backgrounds, -icons, and -examples (or only those
required, you may want to leave out -examples from the
dependency list).
package-backgrounds
* Contains backgrounds.
* May be installed separately (no dependencies).
package-icons
* Contains icons.
* May be installed separately (no dependencies).
package-examples
* Contains examples.
* Depends on package.
Sounds better to me.
What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
meaning of those in the debian policy either? Why not just put depends of
the splited package in the depends line instead of this?
This question still remains open to me.
Joe
_
MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl
Re: Separating packages.
On Mon, 2004-04-05 at 14:55, n.v.t n.v.t wrote:
> What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
> meaning of those in the debian policy either? Why not just put depends of
> the splited package in the depends line instead of this?
You can manually enter the dependencies of each package, that's fine --
but it could be a lot of work for a human. Debhelper is there to help
you.
${shlibs:Depends} and ${misc:Depends} are documented in the debhelper
documentation [0]. Basically, ${misc:Depends} tells debhelper to insert
dependencies for packages that you need because you have used some
debhelper feature. ${shlibs:Depends} is a debhelper program that
generates a shlibs file for shared libraries.
They are useful because they will save you some typing, and if something
changes in debhelper or in your package, you don't have to work out the
dependencies manually -- debhelper will take care of it for you.
Of course, if you don't use debhelper in your package (you should :) or
if your package doesn't have shared libraries, then you don't need
these. There are other such substitution variables, such as
${perl:Depends} for perl packages, and ${python:Depends} for python
packages.
[0] Type "man debhelper".
Cheers,
--
Fabian Fagerholm <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: Separating packages.
On Mon, Apr 05, 2004 at 06:11:57PM +0300, Fabian Fagerholm wrote:
> On Mon, 2004-04-05 at 14:55, n.v.t n.v.t wrote:
> > What does the ${shlibs:Depends}, ${misc:Depends} mean? I can't find the
> > meaning of those in the debian policy either? Why not just put depends of
> > the splited package in the depends line instead of this?
>
> You can manually enter the dependencies of each package, that's fine --
> but it could be a lot of work for a human. Debhelper is there to help
> you.
>
> ${shlibs:Depends} and ${misc:Depends} are documented in the debhelper
> documentation [0]. Basically, ${misc:Depends} tells debhelper to insert
> dependencies for packages that you need because you have used some
> debhelper feature. ${shlibs:Depends} is a debhelper program that
> generates a shlibs file for shared libraries.
Actually, ${shlibs:Depends} is implemented by dpkg-shlibdeps, in
dpkg-dev. dh_shlibdeps in debhelper is a trivial wrapper around it.
> Of course, if you don't use debhelper in your package (you should :) or
> if your package doesn't have shared libraries, then you don't need
> these.
Every package containing dynamically linked binaries should use
${shlibs:Depends}.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Re: Separating packages.
Hi, Ok, that seems to be all clear to me, what about the rules file? How do I separate packages, the example that Andreas Metzler told me to check out, doesn't clear things entirely. Is this the way we should learn it, by examples? So I move files into a directory then create a deb out of each package? A " make " (destdir or something similar like that?) parameter, how should this be done? What am I missing here? Please cc me, I'm not subscribed. Joe _ MSN Zoeken helpt je om de gekste dingen te vinden! http://search.msn.nl
Re: Separating packages.
I'm sorry I forgot to give a example , the structure of the packge looks like this: dir/icon dir/backgrounds dir/examples They all have a Makefile ofcourse in each directory. Joe _ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/
Re: Separating packages.
On Monday 05 April 2004 14:31, Andreas Metzler wrote: > On Mon, Apr 05, 2004 at 09:24:10AM +, WHAT'SYOURNAME wrote: > > I'm debianizing a package that I would like to split up, like: > > package-backgrounds > > package-icons > > package-examples > > Why? How big are the components? Would somebdy e.g install > package-name without package-icons or the other way round? >cu andreas Contemplate debian-policy 11.8: Programs for the X Window System. (It is clearer, wrt. to your question, in older policy versions). No micro management of components that are installed together anyway. (Dpkg has to read the whole database on every system every time;). I have (taken over) such a package, and while it even makes some sense with that specific pkg, which is why i haven't changed it yet, it is a constant pain for me and users of it - i know what i tell you about ;-) Have a nice day, martin
Re: Separating packages.
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > Hello all. > > I have simple question which I could not find in the debian policy, maybe > someone could point me out to that section or the right documentation? Or a > explanation would be nice. I'm debianizing a package that I would like to > split up in several parts, the package has a 'backgrounds' directory a > 'icons' directory and a 'examples' directory. How do I handle this? I would > like to create packages like: > > package-backgrounds > package-icons > package-examples > package-name (which contains all of the above) Should I do this as a > meta-package? How do I create a meta-package? Is it really necessary to split it up like this? What is gained by placing the icons and backgrounds in separate packages? If the program isn't useful without this data, then it should be included in the same package with the program, unless (for example) it is very large and could benefit from being moved into an architecture: all package. Even in that case, do the backgrounds and icons need to be separate? -- - mdz
Re: Separating packages.
On Mon, Apr 05, 2004 at 12:57:55PM +, n.v.t n.v.t wrote: > >Why? How big are the components? Would somebdy e.g install package-name > >without package-icons or the other way round? > > It was a example. The person might only want the backgrounds or only the > icons. This alone is not sufficient reason for producing four packages instead of one. This wastes resources in many places (the Debian package list, the dpkg database, etc.). You must consider whether the benefit is worth the cost. Certainly, the user might only want some of the things in the package. But would it hurt him to have all of it? -- - mdz
Re: Separating packages.
On Mon, 2004-04-05 at 20:16, n.v.t n.v.t wrote: > Ok, that seems to be all clear to me, what about the rules file? How do I > separate packages, the example that Andreas Metzler told me to check out, > doesn't clear things entirely. Is this the way we should learn it, by > examples? So I move files into a directory then create a deb out of each > package? A " make " (destdir or something similar like that?) parameter, how > should this be done? What am I missing here? This is perhaps the most difficult thing to understand about Debian packaging. It's implied in several places, and it's briefly spelt out in some other places, but in general, you are referred to "examples" which vary as much as the packages in the Debian archive. In basic terms, when you build a package, the files generated by the build process are placed in debian/packagename, a directory which is generated by the build tools (they look at the control file for the names). The contents of that directory corresponds to the contents of the deb package "packagename". This means that if you place a file in debian/packagename, it will show up in the package. So what you need to do is make sure the right files end up in the right debian/packagename directory. Because it's a good idea to use debhelper, you should use dh_install to move the files in place. You said you have the following structure: dir/icon dir/backgrounds dir/examples So, in the build target of the rules file, you run the makefile for each of these (or if another makefile already does that, you may omit it, it depends on how the upstream build system is constructed). Now, your package probably comes with an install script that will install the files in their correct destinations. Let's say the package installs the icons, backgrounds and examples using a structure as described above. Then you need to dh_install the contents of each directory into the correct debian/packagename directory. You do this (for example) by saying something like dh_install -ppackagename dir/icon dir/in/package in the install target of the rules file. Here, dir/icon is relative to the source directory (the directory containing debian/ and upstream's sources). Read man dh_install for the complete details. You can then remove the unneccessary directories from the main package (with rm). Another way, which may be better because it reduces the chance that you include a file which wasn't meant to be included, is to have the package install into debian/tmp. Then you dh_install each file and directory into the appropriate package. debian/tmp is then removed in the clean target along with any unneccessary stuff. You have received responses pointing out that there are many important subtleties to be considered when making a split package. You should consider them good advice. I'm just explaining "how to do it" because I found this to be the most difficult thing to understand about deb packaging (probably because it's so simple :) -- but I haven't said anything about "why you should or shouldn't do it". Hope this clears things out for you! Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]>
Re: Separating packages.
On Tue, 2004-04-06 at 08:45, Matt Zimmerman wrote: > This alone is not sufficient reason for producing four packages instead of > one. This wastes resources in many places (the Debian package list, the > dpkg database, etc.). You must consider whether the benefit is worth the > cost. Of course, with the current version of dpkg, your point is very good and entirely valid. Thinking ahead, wouldn't it be a good idea to fix dpkg and the package list to support a larger number of packages? The number of packages in Debian has been constantly growing, and if I'm not mistaken, a release of sarge would include somewhere between 1 and 15000 packages. A presumptive sarge+1 could very well have much more than 15000 packages. If sarge is released any time soon, then a few split packages won't be a big deal. If it isn't, there will certainly be a lot more packages in testing, perhaps enough to require this change of dpkg and the package list anyway. So is the cost really that great? Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]>
Re: Separating packages.
* Fabian Fagerholm <[EMAIL PROTECTED]> [040405 12:10]: > I don't think you need a meta package. I would do this to allow > flexibility and save space: > > package > * Contains all the files not in the other packages. > * Depends on -backgrounds, -icons, and -examples (or only those > required, you may want to leave out -examples from the > dependency list). I suggest recommends or suggests here. If it is really a depend, then they should be in the same package. Even recommend sounds a bit strong for things like that. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Separating packages.
On Tue, 2004-04-06 at 11:49, Bernhard R. Link wrote: > > package > > * Contains all the files not in the other packages. > > * Depends on -backgrounds, -icons, and -examples (or only those > > required, you may want to leave out -examples from the > > dependency list). > > I suggest recommends or suggests here. If it is really a depend, then > they should be in the same package. Even recommend sounds a bit strong > for things like that. Why? If the data packages are useful on their own, and if they are sufficiently large, then a split is certainly a good idea -- at least from the user's point of view. But if the main package depends on the data, then not having a depends-relationship would break the software. I'm sure that's the least desirable option? Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]>
Re: Separating packages.
On Tue, Apr 06, 2004 at 08:18:55AM -0400, Erik Bourget wrote: > Fabian Fagerholm <[EMAIL PROTECTED]> writes: > > > > > Thanks! (to you and everyone who pitched in). d-m is really friendly. Because Fabian wrote: > This is perhaps the most difficult thing to understand about Debian > packaging. It's implied in several places, and it's briefly spelt out in > some other places, but in general, you are referred to "examples" which > vary as much as the packages in the Debian archive. Maybe it's an idea to improve the available documents? (thinking NM guide) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Separating packages.
On Tue, Apr 06, 2004 at 11:29:54AM +0300, Fabian Fagerholm wrote: > Of course, with the current version of dpkg, your point is very good and > entirely valid. > > Thinking ahead, wouldn't it be a good idea to fix dpkg and the package > list to support a larger number of packages? The problem with the package list is simply that it is too large. This is a problem for low-bandwidth users and users with small amounts of memory, for example. It also makes package management UIs harder to navigate, produces additional work for tools which must process each binary package, makes package searches less likely to find the right thing... > The number of packages in Debian has been constantly growing, and if I'm > not mistaken, a release of sarge would include somewhere between 1 and > 15000 packages. A presumptive sarge+1 could very well have much more than > 15000 packages. Yes, we have more than enough growth from adding new software; there is no need to compound the problem with unnecessary splits. -- - mdz
Re: Separating packages.
On Tue, 2004-04-06 at 07:42, Matt Zimmerman wrote: > On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > > > Hello all. > > > > I have simple question which I could not find in the debian policy, maybe > > someone could point me out to that section or the right documentation? Or a > > explanation would be nice. I'm debianizing a package that I would like to > > split up in several parts, the package has a 'backgrounds' directory a > > 'icons' directory and a 'examples' directory. How do I handle this? I would > > like to create packages like: > > > > package-backgrounds > > package-icons > > package-examples > > package-name (which contains all of the above) Should I do this as a > > meta-package? How do I create a meta-package? > > Is it really necessary to split it up like this? What is gained by placing > the icons and backgrounds in separate packages? Hi, This all sounds to me like a complete theme package. Does this package also contains gtk themes? If so, then it would be a good idea to separate the gtk and gtk2 themes. But from what I don't understand is why do you want to separate the backgrounds/icons/examples from each other? I debianizing the redhat-artwork (not for the official repository) but for personal gain and experience. What are you trying to package? Arvind Arvind Autar | GnuPG-Key ID: 336E5788 Key fingerprint = FAB8 B3E5 0059 880A 00B8 C859 350E BBDC 336E 5788 signature.asc Description: This is a digitally signed message part
Re: Separating packages.
On Tue, 2004-04-06 at 18:38, Matt Zimmerman wrote: > The problem with the package list is simply that it is too large. This is a > problem for low-bandwidth users and users with small amounts of memory, for > example. > > It also makes package management UIs harder to navigate, produces additional > work for tools which must process each binary package, makes package > searches less likely to find the right thing... I'm inclined to believe that there are some things that could be done about this if someone wanted to. Diffs for the package list has been proposed, and it doesn't take many minutes of thinking to see that it's actually quite possible to do for a stable release (infrequent changes). Making the package database efficient for the purposes you describe is definitely not impossible either, even with a large list of packages. > Yes, we have more than enough growth from adding new software; there is no > need to compound the problem with unnecessary splits. From a usability perspective, the technical problems of the package management system are uninteresting. Presenting the packages in a well-organized, easily searchable way and letting the user choose what to install and what not to install is the primary goal. If splitting a package supports a group of users, and the split doesn't affect the needs of other groups of users, then I think "the package management system doesn't scale" is a bad excuse for not making the split. Unneccessary splits should of course be avoided, always. Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Separating packages.
On Wed, Apr 07, 2004 at 01:18:11PM +0300, Fabian Fagerholm wrote: > I'm inclined to believe that there are some things that could be done > about this if someone wanted to. Diffs for the package list has been > proposed, and it doesn't take many minutes of thinking to see that it's > actually quite possible to do for a stable release (infrequent changes). > Making the package database efficient for the purposes you describe is > definitely not impossible either, even with a large list of packages. Certainly there are things which could be done to help. I didn't say that the problems were insoluble, but they do exist, and you haven't even begun to consider them all (many different pieces of infrastructure are affected). > From a usability perspective, the technical problems of the package > management system are uninteresting. Presenting the packages in a > well-organized, easily searchable way and letting the user choose what to > install and what not to install is the primary goal. If splitting a > package supports a group of users, and the split doesn't affect the needs > of other groups of users, then I think "the package management system > doesn't scale" is a bad excuse for not making the split. That's the point, though; the split _does_ affect the needs of other groups of users (in many cases, nearly every user of Debian, even if they don't even realize the existence of the package), and the problems are not limited to "[some parts of] the package management system [don't] scale" (though that would be enough for a maintainer to consider). -- - mdz
Re: Separating packages.
On Wed, 2004-04-07 at 19:45, Matt Zimmerman wrote: > Certainly there are things which could be done to help. I didn't say that > the problems were insoluble, but they do exist, and you haven't even begun > to consider them all (many different pieces of infrastructure are affected). Ok, I admit I haven't considered all the related problems. I probably know too little to be able to find them all. However, I'm then left with only one way to look at this: either this is a problem that cannot be solved, or the flaws that lead to this go deeper than I thought. If you're right and the problems are solvable, then this sure is one mammoth of a problem. Let me put it this way: disregarding the particulars of any package management system, doesn't it sound silly that you can't split packages when it would fit a purpose? If there is a non-technical reason, then there's no problem and the package shouldn't be split. But if the reason, however large and complicated, is technical, then that's no reason at all -- it's a challenge to be solved. Well, I realize that the next thing I'd have to do is to stop whining and write the code to solve all these problems and remove any technical obstacles to split every single file in all the Debian packages into a package per file. Maybe I will. Maybe someone else will. But I doubt it will be done as long as the approach is to value what we have more than what we could have... Anyway, interesting discussion. If anyone has any further information, I'd be glad to learn more about it! Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Separating packages.
On Tue, Apr 06, 2004 at 10:18:57AM +0200, Arvind Autar wrote: > On Tue, 2004-04-06 at 07:42, Matt Zimmerman wrote: > > On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > > > > > Hello all. > > > > > > I have simple question which I could not find in the debian policy, maybe > > > someone could point me out to that section or the right documentation? Or > > > a > > > explanation would be nice. I'm debianizing a package that I would like to > > > split up in several parts, the package has a 'backgrounds' directory a > > > 'icons' directory and a 'examples' directory. How do I handle this? I > > > would > > > like to create packages like: > > > > > > package-backgrounds > > > package-icons > > > package-examples > > > package-name (which contains all of the above) Should I do this as a > > > meta-package? How do I create a meta-package? > > > > Is it really necessary to split it up like this? What is gained by placing > > the icons and backgrounds in separate packages? > > Hi, > > This all sounds to me like a complete theme package. Does this package > also contains gtk themes? If so, then it would be a good idea to > separate the gtk and gtk2 themes. But from what I don't understand is > why do you want to separate the backgrounds/icons/examples from each > other? I debianizing the redhat-artwork (not for the official > repository) but for personal gain and experience. What are you trying to > package? I'm also curious about it, so this is a resend with it a CC to the unsubscribed original poster > > Arvind Cheers Geert Stappers
