-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello, I would like to ask you, why was a package "alien" removed from RH distros? Alien is a program that converts between the rpm, dpkg, stampede slp, and slackware tgz file formats. (http://kitenet.net/~joey/code/alien/)
Thanks
- -- Zdenek Prikryl zprikryl@redhat.com Software Engineer - Base Operating Systems Brno
"ZP" == Zdenek Prikryl writes:
ZP> Hello, I would like to ask you, why was a package "alien" removed ZP> from RH distros? Alien is a program that converts between the ZP> rpm, dpkg, stampede slp, and slackware tgz file ZP> formats. (http://kitenet.net/~joey/code/alien/)
I think it was removed a long time ago before Fedora (I think maybe back in the Red Hat 8 or 9 days, perhaps?), it's not even listed as orphaned in the PackageDB:
https://admin.fedoraproject.org/pkgdb/packages/name/alien
gives a 404.
There's no reason it couldn't be readded, AFAICT, if you wanted to become a contributor to the Fedora package collection:
http://fedoraproject.org/wiki/PackageMaintainers/Join
Alex
On 12/05/2007 03:10 PM, Alex Lancaster wrote:
"ZP" == Zdenek Prikryl writes:
ZP> Hello, I would like to ask you, why was a package "alien" removed ZP> from RH distros? Alien is a program that converts between the ZP> rpm, dpkg, stampede slp, and slackware tgz file ZP> formats. (http://kitenet.net/~joey/code/alien/)
I think it was removed a long time ago before Fedora (I think maybe back in the Red Hat 8 or 9 days, perhaps?), it's not even listed as orphaned in the PackageDB:
https://admin.fedoraproject.org/pkgdb/packages/name/alien
gives a 404.
There's no reason it couldn't be readded, AFAICT, if you wanted to become a contributor to the Fedora package collection:
http://fedoraproject.org/wiki/PackageMaintainers/Join
Alex
Last time included in RH, was EL 2.1
http://fr2.rpmfind.net/linux/rpm2html/search.php?query=alien&submit=Sear......
PLD and OpenSuSE have RPMs, TurboLinux also. If someone wants to include alien, PLD specfile might be a good starting point...
-of
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think it was removed a long time ago before Fedora (I think maybe back in the Red Hat 8 or 9 days, perhaps?)
Yes, I found alien in RH-[78], but then was removed. And nobody knows why :-)
There's no reason it couldn't be readded, AFAICT, if you wanted to become a contributor to the Fedora package collection:
If I don't find some important reason, why I shouldn't add this to fedora, then I'll try to be a maintainer.
Thanks
- -- Zdenek Prikryl zprikryl@redhat.com Software Engineer - Base Operating Systems Brno
On 12/05/2007 03:27 PM, Zdenek Prikryl wrote:
I think it was removed a long time ago before Fedora (I think maybe back in the Red Hat 8 or 9 days, perhaps?)
Yes, I found alien in RH-[78], but then was removed. And nobody knows why :-)
There's no reason it couldn't be readded, AFAICT, if you wanted to become a contributor to the Fedora package collection:
If I don't find some important reason, why I shouldn't add this to fedora, then I'll try to be a maintainer.
The question is: It has been absent for a long time now, so it seems nobody really needs it, does someone? :-)
Well. I guess there are a lot of pkgs that only a few guys do use in reality, so go for it. Package it. Share it. Use it.
Best, Oliver
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The question is: It has been absent for a long time now, so it seems nobody really needs it, does someone? :-)
at least, I use it sometimes (not very often, but...sometimes yes) :-)...
- -- Zdenek Prikryl zprikryl@redhat.com Software Engineer - Base Operating Systems Brno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think it was removed a long time ago before Fedora (I think maybe back in the Red Hat 8 or 9 days, perhaps?),
Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't problem. But reverse conversion is big problem. For example, if I want to convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are debian packages for creating deb files. All of those packages aren't in fedora repos.
So, question is, if one-way conversion is a sufficient reason to create alien package. Other solution is create another package (like deb in OpenSUSE) which contains those debian packages and make alien dependant on this new package. Or let alien be forgotten henceforth.
- -- Zdenek Prikryl zprikryl@redhat.com Software Engineer - Base Operating Systems Brno
On 12/05/2007 05:19 PM, Zdenek Prikryl wrote:
I think it was removed a long time ago before Fedora (I think maybe back in the Red Hat 8 or 9 days, perhaps?),
Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't problem. But reverse conversion is big problem. For example, if I want to convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are debian packages for creating deb files. All of those packages aren't in fedora repos.
So, question is, if one-way conversion is a sufficient reason to create alien package. Other solution is create another package (like deb in OpenSUSE) which contains those debian packages and make alien dependant on this new package. Or let alien be forgotten henceforth.
I think you start with one-way version (if you like) and try to get the missing links into Fedora as well and then switch your alien pkg to rebuild and/or use the missing bits...
Else, get the deb bits into Fedora and afterwards alien itself... Which sounds for me like the best idea....
-of
On Wed, Dec 05, 2007 at 05:24:30PM +0100, Oliver Falk wrote:
I think you start with one-way version (if you like) and try to get the missing links into Fedora as well and then switch your alien pkg to rebuild and/or use the missing bits...
Else, get the deb bits into Fedora and afterwards alien itself... Which sounds for me like the best idea....
Indeed, it seems to me that alien should depend on dpkg. I have packages available for dpkg, and other debian stuff (and debootstrap is already in fedora):
http://www.environnement.ens.fr/perso/dumas/fc-srpms/debian/
-- Pat
On 12/05/2007 05:41 PM, Patrice Dumas wrote:
On Wed, Dec 05, 2007 at 05:24:30PM +0100, Oliver Falk wrote:
I think you start with one-way version (if you like) and try to get the missing links into Fedora as well and then switch your alien pkg to rebuild and/or use the missing bits...
Else, get the deb bits into Fedora and afterwards alien itself... Which sounds for me like the best idea....
Indeed, it seems to me that alien should depend on dpkg. I have packages available for dpkg, and other debian stuff (and debootstrap is already in fedora):
http://www.environnement.ens.fr/perso/dumas/fc-srpms/debian/
Well then Zdenek, get the specs. Do a cleanup, run rpmlint, upload somewhere and file a review request :-)
-of
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrice Dumas napsal(a):
Indeed, it seems to me that alien should depend on dpkg. I have packages available for dpkg, and other debian stuff (and debootstrap is already in fedora):
http://www.environnement.ens.fr/perso/dumas/fc-srpms/debian/
I went through your spes file of dpkg and found, that you're doing some renaming of executables, which could be already in fedora. But I thing, that if other dpkg scripts want to use for example install-info, then it will use fedora's install-info instead renamed install-info from dpkg package. So, are these renamed executables needed in package? If not, we can make package without them.
- -- Zdenek Prikryl zprikryl@redhat.com Software Engineer - Base Operating Systems Brno
On Wed, Feb 20, 2008 at 11:34:11AM +0100, Zdenek Prikryl wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrice Dumas napsal(a):
Indeed, it seems to me that alien should depend on dpkg. I have packages available for dpkg, and other debian stuff (and debootstrap is already in fedora):
http://www.environnement.ens.fr/perso/dumas/fc-srpms/debian/
I went through your spes file of dpkg and found, that you're doing some renaming of executables, which could be already in fedora. But I thing, that if other dpkg scripts want to use for example install-info, then it will use fedora's install-info instead renamed install-info from dpkg package. So, are these renamed executables needed in package? If not, we can make package without them.
It doesn't hurt to have them, though. For example one would want to test the debian install-info in parallel with the fedora texinfo one. It would be harder to have dpkg use them during package install, but so far installation of packages using dpkg isn't possible.
Also most of them are perl script so people can look at them, which is nice.
-- Pat
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think you start with one-way version (if you like) and try to get the missing links into Fedora as well and then switch your alien pkg to rebuild and/or use the missing bits...
Else, get the deb bits into Fedora and afterwards alien itself... Which sounds for me like the best idea....
I think that second option is better.
- -- Zdenek Prikryl zprikryl@redhat.com Software Engineer - Base Operating Systems Brno
On Dec 5, 2007 11:19 AM, Zdenek Prikryl zprikryl@redhat.com wrote:
Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't problem. But reverse conversion is big problem. For example, if I want to convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are debian packages for creating deb files. All of those packages aren't in fedora repos.
Debian has the inverse, namely, it has all the packages to create RPMs.
+1 if the ability to turn RPMs into DEBs show up. It could make getting multi-distro support for Smolt easier.
-Yaakov
Though, will dpkg and the like be purposely crippled on Fedora like rpm is on Debian systems? It probably would be a good idea to patch dpkg and stuff to make sure they don't work as standard packagers, but rather just helpers to alien, as RPM does on a Debian system. We want to avoid the possibility of package jumbling.....
On Dec 5, 2007 12:58 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
On Dec 5, 2007 11:19 AM, Zdenek Prikryl zprikryl@redhat.com wrote:
Hmm after little investigation I found, that convert deb, tgz, slp to rpm isn't problem. But reverse conversion is big problem. For example, if I want to convert rmp do deb, I have to have installed dpkg[-dev] and debhelper, which are debian packages for creating deb files. All of those packages aren't in fedora repos.
Debian has the inverse, namely, it has all the packages to create RPMs.
+1 if the ability to turn RPMs into DEBs show up. It could make getting multi-distro support for Smolt easier.
-Yaakov
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, Dec 05, 2007 at 06:51:44PM -0600, King InuYasha wrote:
Though, will dpkg and the like be purposely crippled on Fedora like rpm is on Debian systems? It probably would be a good idea to patch dpkg and stuff to make sure they don't work as standard packagers, but rather just helpers to alien, as RPM does on a Debian system. We want to avoid the possibility of package jumbling.....
I have tried and dpkg fails when launched as a package manager, so I think it is safe. Moreover it could be possible to use it to install in a chroot, so crippling it is a bad idea in my opinion.
-- Pat
On Dec 5, 2007 3:51 PM, King InuYasha ngompa13@gmail.com wrote:
Though, will dpkg and the like be purposely crippled on Fedora like rpm is on Debian systems? It probably would be a good idea to patch dpkg and stuff to make sure they don't work as standard packagers, but rather just helpers to alien, as RPM does on a Debian system. We want to avoid the possibility of package jumbling.....
I would certainly concur with this. Without making a judgment as to the value of having alien or other alternative packaging tools in the repository.. I would agree that if we are going to be putting dpkg and friends into the repository that they come configured by default to only act as helpers for using Fedora as a (re)packaging host. Enabling functionality beyond that should be relatively difficult to enable if not disabled entirely at buildtime. There maybe some rather clever unorthodox ways to make use of a fully capable dpkg in other ways, but I don't want users accidental stumbling into those situations just because they installed dpkg and followed a google'd recipe article to have dpkg replace rpm on their Fedora system.
-jef
On Thu, 2007-12-06 at 12:50 -0900, Jeff Spaleta wrote:
I would certainly concur with this. Without making a judgment as to the value of having alien or other alternative packaging tools in the repository.. I would agree that if we are going to be putting dpkg and friends into the repository that they come configured by default to only act as helpers for using Fedora as a (re)packaging host. Enabling functionality beyond that should be relatively difficult to enable if not disabled entirely at buildtime. There maybe some rather clever unorthodox ways to make use of a fully capable dpkg in other ways, but I don't want users accidental stumbling into those situations just because they installed dpkg and followed a google'd recipe article to have dpkg replace rpm on their Fedora system.
I once installed FC2 by hand, using debian's rpm, to hot-convert said debian machine to Fedora. :)
And I kept notes:
http://www.haxxed.com/random/fedorainstall.txt
Its actually the oldest surviving Fedora install I have, and is still in use. Its survived apt-rpm upgrades up to FC5 or so, and its been yum upgrades since then. And survived most of the hardware being replaced and a total re-purposing. It was originally a firewall box, but was replaced by a (Linux based) wireless router and re-purposed as an "HTPC"...
On Thu, Dec 06, 2007 at 12:50:25PM -0900, Jeff Spaleta wrote:
On Dec 5, 2007 3:51 PM, King InuYasha ngompa13@gmail.com wrote:
Though, will dpkg and the like be purposely crippled on Fedora like rpm is on Debian systems? It probably would be a good idea to patch dpkg and stuff to make sure they don't work as standard packagers, but rather just helpers to alien, as RPM does on a Debian system. We want to avoid the possibility of package jumbling.....
I would certainly concur with this. Without making a judgment as to the value of having alien or other alternative packaging tools in the repository.. I would agree that if we are going to be putting dpkg and friends into the repository that they come configured by default to only act as helpers for using Fedora as a (re)packaging host. Enabling functionality beyond that should be relatively difficult to
I don't think that we should do anything special with dpgk. Just recompile it as is from upstream. If users are dumb and use dpkg to install packages it is their responsibility. Just like when they do ./configure --prefix=/use --sysconfdir=/etc && make && make install Or use CPAN. Our responsibility is integration, not being smart for dumb users.
enable if not disabled entirely at buildtime. There maybe some rather clever unorthodox ways to make use of a fully capable dpkg in other ways, but I don't want users accidental stumbling into those situations just because they installed dpkg and followed a google'd recipe article to have dpkg replace rpm on their Fedora system.
I can't see what is wrong with having 'dpkg replace rpm on their Fedora system' if it works and it is what the user intends to do.
The target for dpkg are not casual users, and casual users won't use it anyway. In %description, I put
dpkg and dselect will certainly be non-functional on a rpm-based system because packages dependencies will likely be unmet.
It may admitedly be enhanced, to say something like
dpkg and dselect will certainly be non-functional on a rpm-based system because packages dependencies will likely be unmet, and in any case you are likely to trash your system if you install packages using dpkg.
-- Pat
Patrice Dumas <pertusus <at> free.fr> writes:
The target for dpkg are not casual users, and casual users won't use it anyway. In %description, I put
dpkg and dselect will certainly be non-functional on a rpm-based system because packages dependencies will likely be unmet.
It may admitedly be enhanced, to say something like
dpkg and dselect will certainly be non-functional on a rpm-based system because packages dependencies will likely be unmet, and in any case you are likely to trash your system if you install packages using dpkg.
I think you should not only say what does not work, but also what does work, so people know why you're packaging them in the first place, e.g.:
dpkg and dselect are provided to allow converting between package formats with alien and installing Debian or Debian-based distributions in a chroot for virtualization. They are NOT intended to be used to manage packages within your Fedora installation, and attempting to use it that way will not work and may even break your system!
Kevin Kofler
On Dec 7, 2007 4:24 AM, Patrice Dumas pertusus@free.fr wrote:
The target for dpkg are not casual users, and casual users won't use it anyway.
And when someone wants to put a dpkg-enabled tool in the distro that does target casual users? It's a slippery slope. We avoid being on that slope by not having a fully functional dpkg on the system at all.
-jef
On Fri, Dec 07, 2007 at 07:40:34AM -0900, Jeff Spaleta wrote:
On Dec 7, 2007 4:24 AM, Patrice Dumas pertusus@free.fr wrote:
The target for dpkg are not casual users, and casual users won't use it anyway.
And when someone wants to put a dpkg-enabled tool in the distro that does target casual users?
What kind of tool are you thinking of? If we have tools that use dpkg then there is a lack of proper integration. The solution is not to have a non functional dpkg, but properly integrated packages.
It's a slippery slope. We avoid being on that slope by not having a fully functional dpkg on the system at all.
It is better if the dpkg we give is upstream dpkg, such that user can use it in any way they want.
-- Pat
On Dec 7, 2007 11:40 AM, Jeff Spaleta jspaleta@gmail.com wrote:
On Dec 7, 2007 4:24 AM, Patrice Dumas pertusus@free.fr wrote:
The target for dpkg are not casual users, and casual users won't use it anyway.
And when someone wants to put a dpkg-enabled tool in the distro that does target casual users? It's a slippery slope. We avoid being on that slope by not having a fully functional dpkg on the system at all.
Do you want to hassle most people that have a legitimate use just to protect everyone else? My level of tolerance is a one time warning, and then for all security features to *get out of the way*.
Granted, we probably don't need apt-dpkg in Fedora, and synaptic is a very bad idea in my book, (although I'm sure someone else would disagree,) but it seems crazy to have to bend over backwards because there are stupid people around.
-Yaakov
Not all people accidentally using dpkg would be stupid. Perhaps they are used to a Debian based system, yadda yadda yadda... Anyways, upstream could theoretically be used if a patch was submitted to detect platforms to enable and disable functionality. For instance, on Debian, a dpkg binary would function as the full package manager, with apt as repo manager. On a Fedora machine, dpkg's platform checking would figure out it is fedora and automatically initialize alien functionality, or just fail with an error stating that if you want to use debian packages on this platform, use alien to convert it to the native package format of the platform.
On Dec 8, 2007 8:24 PM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
On Dec 7, 2007 11:40 AM, Jeff Spaleta jspaleta@gmail.com wrote:
On Dec 7, 2007 4:24 AM, Patrice Dumas pertusus@free.fr wrote:
The target for dpkg are not casual users, and casual users won't use
it
anyway.
And when someone wants to put a dpkg-enabled tool in the distro that does target casual users? It's a slippery slope. We avoid being on that slope by not having a fully functional dpkg on the system
at all.
Do you want to hassle most people that have a legitimate use just to protect everyone else? My level of tolerance is a one time warning, and then for all security features to *get out of the way*.
Granted, we probably don't need apt-dpkg in Fedora, and synaptic is a very bad idea in my book, (although I'm sure someone else would disagree,) but it seems crazy to have to bend over backwards because there are stupid people around.
-Yaakov
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, Dec 10, 2007 at 09:55:14PM -0600, King InuYasha wrote:
Not all people accidentally using dpkg would be stupid. Perhaps they are used to a Debian based system, yadda yadda yadda...
Being used to something isn't an excuse for doing something wrong that could have been avoided by understanding what one is doing (and nobody is stupid in my opinion, but some actions are stupid).
Anyways, upstream could theoretically be used if a patch was submitted to detect platforms to enable and disable functionality.
That could be interesting, indeed. Though detecting the platform is certainly not the way to go. What would be relevant would be to detect a rpm database in the installation root. But then you should want to modify autoconf/automake such that a generated makefile doesn't install in rpm managed directories when a rpm database is detected (or we are in fedora).
For instance, on Debian, a dpkg binary would function as the full package manager, with apt as repo manager. On a Fedora
apt is completely different from dpkg (and the apt in fedora knows .rpm, but not .deb). In fedora the repo manager may be smart, yum, apt and certainly other that I don't know (not to mention that urpmi would certainly work fine).
machine, dpkg's platform checking would figure out it is fedora and automatically initialize alien functionality, or just fail with an error stating that if you want to use debian packages on this platform, use alien to convert it to the native package format of the platform.
My guess is that alien doesn't need dpkg at all, but needs dpkg-deb (which even seems to be a different binary). Still not a reason to cripple dpkg.
-- Pat
devel@lists.stg.fedoraproject.org
-
Alex Lancaster -
Callum Lerwick -
Jef Spaleta -
Kevin Kofler -
Neal Gompa -
Oliver Falk -
Patrice Dumas -
Yaakov Nemoy -
Zdenek Prikryl