Jordi Sayol i Salomó Wrote:

> > I don't think you can have a universally accepted (i386, amd64) package. i386 systems will have their packages named without any postfix, but on amd64 distro the packages will. If you add those packages as a requirement they aren't available on the i386 system.
> 
> After replacing "glibc-devel" whit "glibc-devel(x86-32)" on Requires: tag, the package properly installs on a Fedora-core-13 32 bits.

Ok, that would be a difference from RPM and Deb.


> >>>> Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I don't like this solution because when dmd 64 bits appears in the near future, this will be a source of confusion.
> >>> yeah, don't do that.
> >> I'll not :-)
> > 
> > This is actually the proper way to create these packages. There won't be any confusion; when the 64bit version becomes usable the package will then contain a native 64bit compiler and won't have the dependencies on 32bit packages. If you really think it is a problem name the package dmd-ia32 or whatever and then the native 64bit compiler will replace that package.
> 
> Do You really thinks that is necessary to create a 32 bits dmd rpm/deb packages to install them on 64 bits OS? With a few easy steps You can do the same with the 32 bits OS packages.

I'll ask you this, for RPM if it is stated to be a 32 bit package, can you installed it without "forcing" the install on a 64 bit system?

Since RPM can request a 32 bit version of a package it seems you are able to keep the same package, unless the 64 bit system needs extra packages.


> >>>> And My preferred solution, create a i386 chroot machine inside Your x86_64 system, install dmd package on it and compile Yours D programs on it too.
> >>> I've never found a need to do this (and I also don't know how).
> >> Try it! is clean, easy and faster than other virtual machines, for text mode. I don't know how to install it in Fedora.
> >> In Ubuntu just install "debootstrap". On Debian-like systems, chroot is used to build/compile packages for other architectures    than the hostsystem, if it is possible.
> > 
> > You still need the i386 packages installed to provide a proper root environment. I don't see the benefit.
> 
> Sorry but this is no true. If You have a 64 bits system without 32 bits libs, and creates a chroot dir with a 32 bits system in it, You don't need to install any 32 bits lib on host system to run 32 bits programs inside chroot, at least in text mode.

You may not need it on the host environment but it must exsits within the specified root, so you still have the libraries "installed" on the system (for verious definitions of installed)


> >> Another thing about the creation of dmd rpm package. As You know, dmd.conf is a configuration file, and so, it can be changed by another futurepackages (i.e. gtkd o qtd) or by the final user. I think is not a good solution to just put it on the place, otherwise You have to make some checks during the package installation, upgrading and removing process. Checkif the file exist, if not, create it, if exist, modify it to assure thatdmd will properly compile, etc.
> > 
> > No, I don't have my reference to this. You do NOT have multiple packages modify the configuration file! You can either choose a "master" packagethat provides a program to manage the configuration file, or you put that program in a new package which everyone would depend on. This is the practice recommended for building Debian packages.
> 
> Really? If You installs dmd and after installs a gtkd package. How do gtkd give dmd the Include dirs, lib dirs, etc.?
> Do You really thinks that dmd.conf contained on dmd package has to contain all configurations for all the installable packages pending on dmd?

If you go with the "master" method then gtkd would have to require dmd. If you chose to create a separate package (dmdconf-manager) then gtkd would require that package and requests for what is needed in the .conf file would go through it (which may have its own files in /var to remember the system setup).

Now what you would probably have is a libgtkd package and a libgtkd-dev package. libghtkd doesn't care about dmd.conf, but libgtkd-dev would and it wouldn't be unreasonable to depend on d-compiler.

I could just be putting my foot in my mouth with all of this.


> I know that this is the recommended practice for building Debian packages, but a debian packager told me that the only way to do that is handle the dmd.conf with preinst, prerm, postinst and postrm scripts.

You use those for modifying the package config file based on the environment being installed to. Configuration files are supposed to only have one owner. And I agree it is the cleanest way to deal with these issues and doesn't rely on shell scripts to get it right.

> > I hope you find this advice helpful. I am not really the authority on these things, but it is what I have pieced together from what others do for packaging.
> 
> Many thanks.
> 
> -- 
> Jordi Sayol

Yeah, this stuff seems to require quite a bit of planning.

En/na Jesse Phillips ha escrit:
> Jordi Sayol i Salomó Wrote:
> 
>>> I don't think you can have a universally accepted (i386, amd64) package. i386 systems will have their packages named without any postfix, but on amd64 distro the packages will. If you add those packages as a requirement they aren't available on the i386 system.
>> After replacing "glibc-devel" whit "glibc-devel(x86-32)" on Requires: tag, the package properly installs on a Fedora-core-13 32 bits.
> 
> Ok, that would be a difference from RPM and Deb.

Until I know, Yes, it is.

> 
> 
>>>>>> Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I don't like this solution because when dmd 64 bits appears in the near future, this will be a source of confusion.
>>>>> yeah, don't do that.
>>>> I'll not :-)
>>> This is actually the proper way to create these packages. There won't be any confusion; when the 64bit version becomes usable the package will then contain a native 64bit compiler and won't have the dependencies on 32bit packages. If you really think it is a problem name the package dmd-ia32 or whatever and then the native 64bit compiler will replace that package.
>> Do You really thinks that is necessary to create a 32 bits dmd rpm/deb packages to install them on 64 bits OS? With a few easy steps You can do the same with the 32 bits OS packages.
> 
> I'll ask you this, for RPM if it is stated to be a 32 bit package, can you installed it without "forcing" the install on a 64 bit system?

No, You have to force on 64 bits system, but You can assure dependencies in both, 32 and 64 bits systems. The binary rpm packages can only have one destination architecture, like deb.

> 
> Since RPM can request a 32 bit version of a package it seems you are able to keep the same package, unless the 64 bit system needs extra packages.

No, adding correct dependencies, it will work on both archs, I think.

> 
> 
>>>>>> And My preferred solution, create a i386 chroot machine inside Your x86_64 system, install dmd package on it and compile Yours D programs on it too.
>>>>> I've never found a need to do this (and I also don't know how).
>>>> Try it! is clean, easy and faster than other virtual machines, for text mode. I don't know how to install it in Fedora.
>>>> In Ubuntu just install "debootstrap". On Debian-like systems, chroot is used to build/compile packages for other architectures    than the hostsystem, if it is possible.
>>> You still need the i386 packages installed to provide a proper root environment. I don't see the benefit.
>> Sorry but this is no true. If You have a 64 bits system without 32 bits libs, and creates a chroot dir with a 32 bits system in it, You don't need to install any 32 bits lib on host system to run 32 bits programs inside chroot, at least in text mode.
> 
> You may not need it on the host environment but it must exsits within the specified root, so you still have the libraries "installed" on the system (for verious definitions of installed)

Well, this is true but they are clearly separated. Every chroot dir contains a full OS.

> 
> 
>>>> Another thing about the creation of dmd rpm package. As You know, dmd.conf is a configuration file, and so, it can be changed by another futurepackages (i.e. gtkd o qtd) or by the final user. I think is not a good solution to just put it on the place, otherwise You have to make some checks during the package installation, upgrading and removing process. Checkif the file exist, if not, create it, if exist, modify it to assure thatdmd will properly compile, etc.
>>> No, I don't have my reference to this. You do NOT have multiple packages modify the configuration file! You can either choose a "master" packagethat provides a program to manage the configuration file, or you put that program in a new package which everyone would depend on. This is the practice recommended for building Debian packages.
>> Really? If You installs dmd and after installs a gtkd package. How do gtkd give dmd the Include dirs, lib dirs, etc.?
>> Do You really thinks that dmd.conf contained on dmd package has to contain all configurations for all the installable packages pending on dmd?
> 
> If you go with the "master" method then gtkd would have to require dmd. If you chose to create a separate package (dmdconf-manager) then gtkd would require that package and requests for what is needed in the .conf file would go through it (which may have its own files in /var to remember the system setup).
> 
> Now what you would probably have is a libgtkd package and a libgtkd-dev package. libghtkd doesn't care about dmd.conf, but libgtkd-dev would and it wouldn't be unreasonable to depend on d-compiler.

Then, I have to divide dmd into "libdmd", "libdmd-dev" and "dmd" too, isn't it?

> 
> I could just be putting my foot in my mouth with all of this.
> 
> 
>> I know that this is the recommended practice for building Debian packages, but a debian packager told me that the only way to do that is handle the dmd.conf with preinst, prerm, postinst and postrm scripts.
> 
> You use those for modifying the package config file based on the environment being installed to. Configuration files are supposed to only have one owner. And I agree it is the cleanest way to deal with these issues and doesn't rely on shell scripts to get it right.

Interesting. Can You explain a bit more how the "dmdconf-manager" package has to do the job?

> 
>>> I hope you find this advice helpful. I am not really the authority on these things, but it is what I have pieced together from what others do for packaging.
>> Many thanks.
>>
>> -- 
>> Jordi Sayol
> 
> Yeah, this stuff seems to require quite a bit of planning.

Well, one day I wakeup, takes breakfast, and after try to install dmd on my ubuntu but deb package fails on install, and then decide to create my own dmd deb package for personal use, and...   ...here I am, and... :-)


-- 
Jordi Sayol

On 06/25/2010 03:49 PM, Jordi Sayol i Salomó wrote:
>>
>> No, I don't have my reference to this. You do NOT have multiple
>> packages modify the configuration file! You can either choose a
>> "master" packagethat provides a program to manage the configuration
>> file, or you put that program in a new package which everyone would
>> depend on. This is the practice recommended for building Debian packages.
>
> Really? If You installs dmd and after installs a gtkd package. How do
> gtkd give dmd the Include dirs, lib dirs, etc.?
> Do You really thinks that dmd.conf contained on dmd package has to
> contain all configurations for all the installable packages pending on dmd?
>
> I know that this is the recommended practice for building Debian
> packages, but a debian packager told me that the only way to do that is
> handle the dmd.conf with preinst, prerm, postinst and postrm scripts.
>

maybe an alternative would be to just define

/usr/lib/dmd-xxx/
/usr/include/dmd-xxx/

and in dmd.conf:
[Environment]
DFLAGS = -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx

and have any additional library put its stuff directly in those two directories?

En/na Ellery Newcomer ha escrit:
> On 06/25/2010 03:49 PM, Jordi Sayol i Salomó wrote:
>>>
>>> No, I don't have my reference to this. You do NOT have multiple packages modify the configuration file! You can either choose a "master" packagethat provides a program to manage the configuration file, or you put that program in a new package which everyone would depend on. This is the practice recommended for building Debian packages.
>>
>> Really? If You installs dmd and after installs a gtkd package. How do
>> gtkd give dmd the Include dirs, lib dirs, etc.?
>> Do You really thinks that dmd.conf contained on dmd package has to
>> contain all configurations for all the installable packages pending on
>> dmd?
>>
>> I know that this is the recommended practice for building Debian packages, but a debian packager told me that the only way to do that is handle the dmd.conf with preinst, prerm, postinst and postrm scripts.
>>
> 
> maybe an alternative would be to just define
> 
> /usr/lib/dmd-xxx/
> /usr/include/dmd-xxx/
> 
> and in dmd.conf:
> [Environment]
> DFLAGS = -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx
> 
> and have any additional library put its stuff directly in those two directories?

here are missing the linkerflags for the linker

-- 
Jordi Sayol

On 06/26/2010 09:46 AM, Jordi Sayol i Salomó wrote:
>> maybe an alternative would be to just define
>>
>> /usr/lib/dmd-xxx/
>> /usr/include/dmd-xxx/
>>
>> and in dmd.conf:
>> [Environment]
>> DFLAGS = -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx
>>
>> and have any additional library put its stuff directly in those two
>> directories?
>
> here are missing the linkerflags for the linker
>

eh?

On Sat, 26 Jun 2010 15:37:40 +0200, Jordi Sayol i Salomó wrote:
>
>> I'll ask you this, for RPM if it is stated to be a 32 bit package, can you installed it without "forcing" the install on a 64 bit system?
> 
> No, You have to force on 64 bits system, but You can assure dependencies in both, 32 and 64 bits systems. The binary rpm packages can only have one destination architecture, like deb.

Then I think a package should be built for each architecture. For a
Debian repository a separate database is provided for each architecture
so a package must be built for every architecture you wish to have the
package. I guess RPM is not the same in this, so it is of less importance.

I also think it is polite to give everyone a package that will just
install.

>> Now what you would probably have is a libgtkd package and a libgtkd-dev package. libghtkd doesn't care about dmd.conf, but libgtkd-dev would and it wouldn't be unreasonable to depend on d-compiler.
> 
> Then, I have to divide dmd into "libdmd", "libdmd-dev" and "dmd" too, isn't it?

Well, actually the proper way would be to separate it into, libphobos, libphobos-dev, dmd. And libtango is in Debian because of LDC.

>> You use those for modifying the package config file based on the environment being installed to. Configuration files are supposed to only have one owner. And I agree it is the cleanest way to deal with these issues and doesn't rely on shell scripts to get it right.
> 
> Interesting. Can You explain a bit more how the "dmdconf-manager" package has to do the job?

I think you would probably have it take simple arguments; in English, "I am GTKD and will need these options added to dmd.conf." and then removal would just be, "I'm GTKD goodbye."

Since dmd.conf should already have /usr/lib, /usr/include and stuff in it and GTKD should be installing to those directories anyway, I don't know if there is much need to manage such an installation.

En/na Jesse Phillips ha escrit:
> On Sat, 26 Jun 2010 15:37:40 +0200, Jordi Sayol i Salomó wrote:
>>> I'll ask you this, for RPM if it is stated to be a 32 bit package, can you installed it without "forcing" the install on a 64 bit system?
>> No, You have to force on 64 bits system, but You can assure dependencies in both, 32 and 64 bits systems. The binary rpm packages can only have one destination architecture, like deb.
> 
> Then I think a package should be built for each architecture. For a
> Debian repository a separate database is provided for each architecture
> so a package must be built for every architecture you wish to have the
> package. I guess RPM is not the same in this, so it is of less importance.
> 
> I also think it is polite to give everyone a package that will just
> install.
> 
>>> Now what you would probably have is a libgtkd package and a libgtkd-dev package. libghtkd doesn't care about dmd.conf, but libgtkd-dev would and it wouldn't be unreasonable to depend on d-compiler.
>> Then, I have to divide dmd into "libdmd", "libdmd-dev" and "dmd" too, isn't it?
> 
> Well, actually the proper way would be to separate it into, libphobos, libphobos-dev, dmd. And libtango is in Debian because of LDC.

Where to place druntime lib and headers?

> 
>>> You use those for modifying the package config file based on the environment being installed to. Configuration files are supposed to only have one owner. And I agree it is the cleanest way to deal with these issues and doesn't rely on shell scripts to get it right.
>> Interesting. Can You explain a bit more how the "dmdconf-manager" package has to do the job?
> 
> I think you would probably have it take simple arguments; in English, "I am GTKD and will need these options added to dmd.conf." and then removal would just be, "I'm GTKD goodbye."
> 
> Since dmd.conf should already have /usr/lib, /usr/include and stuff in it and GTKD should be installing to those directories anyway, I don't know if there is much need to manage such an installation.

GTKD needs some additional linker-flags to properly link, like "-L-lgtkd"


-- 
Jordi Sayol

On Sat, 26 Jun 2010 17:59:01 +0200, Jordi Sayol i Salomó wrote:

> Where to place druntime lib and headers?

You could then put them in yet another lib package. I realize this is unreasonable when you don't have a repository to pull in everything needed so it is reasonable to place everything in a single package, but then you shouldn't be expecting that package to interact nicely with others.

En/na Jesse Phillips ha escrit:
> On Sat, 26 Jun 2010 17:59:01 +0200, Jordi Sayol i Salomó wrote:
> 
>> Where to place druntime lib and headers?
> 
> You could then put them in yet another lib package. I realize this is unreasonable when you don't have a repository to pull in everything needed so it is reasonable to place everything in a single package,

Yes, of course

> but then you shouldn't be expecting that package to interact nicely with others.

Yes, it will. Look below.

Resuming, the list of packages can be:

"dmd"  including exe files and "dmd.conf.manager" script
"libphobos2-dev"  including phobos headers
"libphobos2-dmd-dev"  including phobos static libraries compiled with dmd
"libdruntime-dev"  including druntime headers
"libdruntime-dmd-dev"  including druntime static libraries compiled with dmd
"dmd-phobos-doc"  including html pages and examples, creating some link on main menu

"libphobos2-dmd" and "libdruntime-dmd" will appears when dmd dynamic libs do.

I'm not quite sure on "libphobos2-dev" - "libphobos2-dmd-dev" and "libdruntime-dev" - "libdruntime-dmd-dev" split.
Another possibility is to join them into "libphobos2-dmd-dev" and "libdruntime-dmd-dev", or just call "libphobos2-dev" => "libphobos2-headers" and "libdruntime-dev" => "libdruntime-headers", as ldc deb packager has done with "tango" libraries and headers.

dependencies:

"dmd"
    depends:
	"libphobos2-dmd-dev"
	"libdruntime-dmd-dev"
	--others packages deeded by dmd to properly compile--
    recomends:
	"dmd-phobos-doc"

"libphobos2-dmd-dev"
    depends:
	"libphobos2-dev"

"libdruntime-dmd-dev"
    depends:
	"libdruntime-dev"

With this sctructure, others packages can interact nicely with dmd now (one package) and in the future, because them will spect the "dmd.conf.manager" script on dmd package, and this do not change after split dmd.

-- 
Jordi Sayol

i do'nt not use this rpm, but one thing in rpm Guideline if a package contain a static lirbrary in package need be *-static
my 2 cents :-)