I'll add Section sometime later. For now survive with  control_fields . Look how many they are, i plan on adding directly what people truly use, for the rest you'll be using control_fields.

the build folder with the DEBBUILD is a custom source package, the custom version in dsc was there to stop you from running the usual debian tools. You use easydeb inside the chroot/container to build the package. Why is that a problem? Trying to convert it seams difficult and error prone, and will probably be ugly... It's a bad idea. The generated debian archive is just the build folder minus the sources. It was never supposed to be processed by debian tools.

You do know what's a chroot right? It's a light container (less secure), it pretends to be a different linux install. You use it for packaging so that you are sure you use the correct build dependencies and environment, then you also install it and run it in a chroot, to test you have all the dependencies. You can just use easydeb inside. The debian tools aren't doing anything magical with a chroot.

instead of complaining. What are the alternatives? fil-C is C with garbage collection, it's slower and less efficient, but you can take your old C code and with relatively few modifications port it in fil-C .With the garbage collection, it's even better then rust in security and you get to keep almost all your battle tested code. And you can still maintain in parallel normal C code for ultra efficiency if you need it. You could even use a hybrid approach for a balance of security and speed. This strategy could allow for a viable fork with less man power.

does sudo needs to be fast? Isn't the user the slowest part? Does apt need to be fast? How much of apt's time is the network download and decompressions?

@spliskin
Just a warning. Lunduke is the tabloid of tech. He often over does it with click bait and sensationalism.

I took the decision to debianise the names so that there's direct correspondence between what the package is saying about it self and the debbuild, normally (unless bugs) i also left backwards compatibility but try avoiding relying on that to avoid confusion. These changes are trivial and straight forward. Beyond that, it should be almost the same.

debian/ubuntu/whatever are not arch, the libs are of different versions and are split differently and they are no -dev packages, the needed commands might need changes for various reasons, rolling vs ltr etc... From this perspective changing names was justified, since you can't just use them.

They will need manual adaptation. The differences are chaotic and can't be automatically converted. It's still better then starting from scratch though.

man pages:

And .... on gitea give me your debbuilds, i'll make you a collaborator for them. (free  gitea is making it awkward to create new repos to insentivise you to pay them, you can create 5 repos max under your user name and organizations, can't git push a new repo, but you can move them any way you like and can make infinite orgs. So you would need to create them under your username, then transfer ownership to DUR.)

@tux_99
No automatic chroot. You'll need to launch that your self, it should work just fine. The design strategy is unix/kiss (specialized and simple). For personal use it's fine like that. Even debian building tools don't automatically use a chroot. You can use it for sloppy personal packages and for high quality packages. You could also use distrobox or anything else of the sort.

buuuug, you don't have firejail installed. Speak of the devil, yes, i'm not using a chroot. tmp fix, install firejail (it's a sandboxing tool). The error, is that it's trying to symlink the firejail profile in the firejail folder that doesn't exist, so that you can use it if you want. You don't have to use firejail, this is why it's not in the dependencies, it's totally optional. I flagged it as prerelease for a reason.

the other is apt specific. I'm guessing because you used full path, it thinks it's doing a download as root. With sudo/doas and ./package i never get this.

@golinux @Babarosa
The strategy of the project is a AUR for debs. It's not "just" a new packaging format for dummies. There's all the arcane stuff you need to do to package stuff. Where you download from, dependencies, commands, patches..... Some stuff are especially badly behaved and you need to straiten them up. Now, every user must redo everything from scratch and hunt down the solution like a windows user. With a deb AUR this stuff can be greatly reduced. You are supposed to share your DEBBUILDs.

peak irony if openbsd doesn't adopt rust. They are the paranoid OS.

@tux_99
It's a general rule of institutions, they are like people. They are born, peak, decline, then die. Institutional decay slowly accumulates, the wrong people get to power, corruption, neglect of the new generation etc, until the institution collapses. Debian's institutions are very old and it shows. I can't tell you exactly what's going to happen, but i can tell you that the long term trend is downwards.

@g4sra
The convention in the AUR is to name variants appropriately with an extension to the name, like package-bin for repackaged upstream binaries or package-git for built git repo versions, just package is for the normal version (a packaged windows only app is just package, if it has a linux variant then it's package-wine and package for the linux version ). Privately you do what you want, but if you upload them to DUR you need to follow the conventions or you'll just confuse people. Your packages should be named package-opt and normally placed in /opt/package and bundle all external( non-system) libs. Maintenership is fluid and not a good indicator of compatibility, packages can change hands, the external lib can be created by some one else, then they are build dependencies.... All this is for a messy repository with many packages from different authors while maintaining it reasonably searchable.

one author can package a library and then an other one use it. libs expect to be seen by everybody. And packages can also change authors.

The convention is to package them normally, you are admitting it your self. You are trying to swim against the current. Conventions change. Back then distro packages where dominant, now external packages are significant.

The potential problems you describe can be managed. If you are doing something critical you'll triple test it anyway. It's up to the user not to over do it.

For the naming convention you create a new standard. The AUR has 100.000 packages and they don't do that. Rename them package-opt to distinguish them from normal packages. The convention is to append something at the end of the name if your package is some special variant. For example -git for git repo packages, -bin for upstream binaries, -wine for windows stuff, -somepatch for a specific patched variant etc.... To keep in line with expectations, -opt packages should be bundling all the stuff the base system doesn't have. So no external libraries, just /opt/package and named package-opt . It's that reasonable to you?

see latest update, i added make install with default to /usr/local. I haven't fully tested /usr/local because i don't want to install untracked files. It worked with normal packaging and in local folder it looked good with usr/local . Look for errors i might missed, including docs.

make install RELEASE="unstable" TARGET="local"

current translations are just AI place holders for testing. release and target are just for version tracking. Translations not supported here, they use gettext and don't know if it's possible to use them in /usr/local .

you weren't supposed to install it directly. it's "make package", not "make install". It's for packaging. Given the circumstances i don't see the point of a make install. Yes i know about /usr/local .

/opt is when all the files are thrown in one folder, example: /opt/firefox /opt/brave . Plenty of non-distro packages install in /usr . You are breaking convention. Yes, i know many third party apps just dump all their stuff in opt.

I'm assuming you found FILESYSTEM_PREFIX ... i guess you can install in /opt/easydeb . I didn't tested moving the prefix in the DEBBUILD. What you are doing is too weird. You are complicating your life for little benefit.

if it's not broken, don't fix it.

I'll take that over reddit mods or patronizing mods over moderating.

You didn't read the readme in easydeb . Clarify what's confusing.

This is a deb packager that packages it self... You expect i'll use "make install"?

1. you download and install the deb package of the release from easydeb. https://gitea.com/easydeb/easydeb/relea … f3_all.deb
2. easydeb is the real repo
3. easydeb-git is the recipe to package it self. it follows aur convention. This packages the latest git version. Because of the way it works, i  couldn't put it inside the main repo. You clone, you enter the folder, then run easydeb. (if build dependencies are missing, it will request "easydeb -s" for installing them, you can block the lengthy checks with "--no-check" )
4. https://gitea.com/DUR a bunch of examples of recipes. Some depend on others to build or install. Also some maybe a bit buggy, i made some mass changes latelly.
5. help:

man debbuild
man easydeb
easydeb --help

debbuild is help for the DEBBUILD  format
the other two are for the command. If something is confusing, tell me.

expect some bugs. Just report them, here or there is fine.

lol, my question? the kernel has rust in it now. Doesn't that mean that the kernel it self has the same problem in regards to platforms supported?

Every now and then, there's a hype train that this or that will solve all of our problems. It was oop or garbage collectors a long time ago... this time it's rust. The no free lunch theorem says there's a price to pay somewhere.

replacing code that was battle tested for decades with new one just because the new language is magical is arrogance to 11.